Add TeX Live and Pandoc installation for ppc64le #1179
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Hi @puneetsharma21. Thanks for your PR. I'm waiting for a opendatahub-io member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
""" WalkthroughA multi-stage Docker build process was introduced for the Jupyter minimal image, adding a dedicated stage to build and install TeX Live and Pandoc using new architecture-aware shell scripts. The final image now copies these prebuilt binaries, and the environment is adjusted accordingly. Two new utility scripts for TeX Live and Pandoc installation were added. Changes
Possibly related PRs
Suggested labels
📜 Recent review detailsConfiguration used: .coderabbit.yaml 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
This comment was marked as outdated.
This comment was marked as outdated.
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (4)
jupyter/utils/install_pdf_deps.sh (3)
13-16: Hard-coded TeX Live 2025 URL is brittlePointing to a specific nightly snapshot (
texlive-20250308-source.tar.xz) risks sudden 404s when mirrors rotate or prune historic files.
Expose the version as a variable and fall back to a mirror list or checksum verification so future rebuilds stay reproducible.
18-21: Temporary build toolchain inflates the final image
dnf installpulls a full compiler stack but it is never removed. Either:
- Perform the build in a separate stage and
COPY --fromonly/opt/texlive/2025, or- Remove RPMs and clean caches after
make install.Both cut the image size by hundreds of MB and reduce CVE surface.
31-36: Symlink & PATH export are not fully reliable
- Use
ln -sfto avoid failures on re-runs when the link already exists.- The
export PATH=…line has no effect outside the script’s process during aRUNlayer. Persisting is already handled in the Dockerfile, so the export can be removed to avoid confusion.jupyter/minimal/ubi9-python-3.11/Dockerfile.cpu (1)
52-52: Path entry for ppc64le is unconditional
/opt/texlive/2025/bin/powerpc64le-unknown-linux-gnuis prepended even on x86_64 builds where the directory does not exist. While harmless, each command invocation incurs an extra failedstatand slightly slows PATH lookup.Consider gating the ENV line on architecture:
ARG ARCH=$(uname -m) RUN if [ "$ARCH" = "ppc64le" ]; then \ echo 'export PATH="/opt/texlive/2025/bin/powerpc64le-unknown-linux-gnu:$PATH"' >> /etc/profile.d/texlive.sh ; \ fi
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
jupyter/minimal/ubi9-python-3.11/Dockerfile.cpu(2 hunks)jupyter/utils/install_pdf_deps.sh(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: Generate job matrix
- GitHub Check: pytest-tests
|
My preferred solution would be to base the workbench images on red hat enterprise linux, instead of ubi, as to have access to xetex rpms. This would mean rhel for shipping product and centos stream for opendatahub version. That way we'd avoid the lengthy build (I am pretty sure it's gonna be lengthy, completely unsuitable for qemu-user emulation, unless caching is employed, and multistage dockerfile is used to improve caching). This is something we'd have to agree on, if we want to go that way. In general, I'd love to see xetex installed from some trustworthy binary artifacts. Most conveniently, these should be built by Red Hat, so we can ship them unrestrainedly in the paid product. |
|
@jiridanek Thanks for the detailed suggestion! You're right — building TeX Live from source is quite heavy and slow, especially under QEMU emulation. However, at this point, sticking with UBI is necessary due to the TeX Live an Pandoc in RHEL is outdated versions lacking features we need. |
This makes no sense, UBI is a subset of RHEL! |
|
@jiridanek Actually, while x86-based RHEL/UBI images ship with more up-to-date versions of TeX Live and Pandoc, Because of this, we’re currently building TeX Live and Pandoc from source on Power — even though it’s resource-intensive — to ensure compatibility and functionality. We're not sure those older versions should be preferred in the long term, especially for advanced notebook workflows. |
|
According to https://access.redhat.com/downloads/content/texlive-xetex/20240311-6.el10/x86_64/fd431d51/package
That's the same versions I see available for x86-64 too. Is this too old for you? Pandoc does not seem to be available in RHEL anymore, it was dropped from distribution in RHEL8. edit: ppc64le same xetex versions
|
|
Thanks, @jiridanek — you're right that the versions listed for RHEL are technically the same across architectures. However., 📌 On x86_64, we use a xetex version from 2025 (installed via upstream binaries or tlmgr), and this is already integrated into our notebook workflows . 📌 On ppc64le, the latest available xetex version in RHEL 9 is still from 2020 |
Signed-off-by: puneetsharma21 <[email protected]>
Signed-off-by: puneetsharma21 <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
jupyter/minimal/ubi9-python-3.12/Dockerfile.cpu (1)
4-4: Use of:latestbase image already tracked in issue #1242 – no further action here
The repeated discussion about pinning the UBI base image is covered by the standing backlog issue; not blocking this PR.
🧹 Nitpick comments (1)
jupyter/minimal/ubi9-python-3.12/Dockerfile.cpu (1)
11-17: Collapse the three RUN layers and delete helper scripts to shrink the builder image
You can shave ~40 MB and speed up caching:-RUN chmod +x install_texlive.sh install_pandoc.sh - -RUN ./install_texlive.sh -RUN ./install_pandoc.sh +RUN chmod +x install_texlive.sh install_pandoc.sh && \ + ./install_texlive.sh && \ + ./install_pandoc.sh && \ + rm -f install_texlive.sh install_pandoc.sh
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
jupyter/minimal/ubi9-python-3.12/Dockerfile.cpu(2 hunks)
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-09T10:24:37.290Z
Learning: jiridanek requested GitHub issue creation for TeX Live installation robustness improvements in jupyter/utils/install_pdf_deps.sh during PR #1357 review, specifically for network resilience and error handling improvements to address flaky CI failures. Issue was created with comprehensive problem description covering network download failures, mirror fallback mechanisms, retry logic, caching strategies, multiple solution options with code examples, detailed acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-09T10:24:37.290Z
Learning: jiridanek requested GitHub issue creation for TeX Live installation robustness improvements in jupyter/utils/install_pdf_deps.sh during PR #1357 review, specifically for network resilience and error handling improvements to address flaky CI failures. Issue #1361 was successfully created with comprehensive problem description covering network download failures, mirror fallback mechanisms, retry logic, caching strategies, multiple solution options with code examples, detailed acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1260
File: jupyter/utils/install_pdf_deps.sh:13-27
Timestamp: 2025-07-03T13:04:11.835Z
Learning: jiridanek requested GitHub issue creation for investigating alternatives to directory move operation in install_pdf_deps.sh during PR #1260 review, specifically to explore cleaner architectural approaches like installing TeX Live directly to /usr/local/texlive/bin instead of using filesystem manipulation post-installation. Issue #1291 was created with comprehensive problem description, multiple solution options, acceptance criteria, and proper context linking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1260
File: jupyter/utils/install_pdf_deps.sh:13-27
Timestamp: 2025-07-03T13:04:11.835Z
Learning: jiridanek requested GitHub issue creation for investigating alternatives to directory move operation in install_pdf_deps.sh during PR #1260 review, specifically to explore cleaner architectural approaches like installing TeX Live directly to /usr/local/texlive/bin instead of using filesystem manipulation post-installation.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-11T11:16:05.096Z
Learning: jiridanek requested GitHub issue creation for RStudio py311 Tekton push pipelines during PR #1379 review. Issue #1384 was successfully created covering two RStudio variants (CPU and CUDA) found in manifests/base/params-latest.env, with comprehensive problem description, implementation requirements following the same pattern as other workbench pipelines, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-11T11:16:05.096Z
Learning: jiridanek requested GitHub issue creation for adding RStudio py311 Tekton push pipelines during PR #1379 review, referencing existing registry entries in manifests/base/params-latest.env but missing corresponding .tekton pipeline files. A comprehensive issue was created with detailed problem description, implementation requirements following the same pattern as other workbench pipelines, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-tensorflow/ubi9-python-3.12/Dockerfile.rocm:50-50
Timestamp: 2025-07-08T19:30:01.738Z
Learning: jiridanek requested GitHub issue creation for multi-architecture support in ROCm TensorFlow image during PR #1333 review. Issue #1346 was created with comprehensive problem description covering hardcoded x86_64 architecture breaking multi-arch support, detailed impact analysis, three solution options (runtime detection, BuildKit TARGETARCH integration, hybrid approach) with pros/cons analysis, comprehensive acceptance criteria covering core requirements and testing, phased implementation guidance, related files identification, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: jupyter/pytorch/ubi9-python-3.12/Dockerfile.cuda:65-66
Timestamp: 2025-07-09T12:31:02.033Z
Learning: jiridanek requested GitHub issue creation for MSSQL repo file hardcoding problem during PR #1320 review. Issue #1363 was created and updated with comprehensive problem description covering hardcoded x86_64 MSSQL repo files breaking multi-architecture builds across 10 affected Dockerfiles (including datascience, CUDA, ROCm, and TrustyAI variants), detailed root cause analysis, three solution options with code examples, clear acceptance criteria for all image types, implementation guidance following established multi-architecture patterns, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: jupyter/pytorch/ubi9-python-3.12/Dockerfile.cuda:42-52
Timestamp: 2025-07-09T12:29:56.162Z
Learning: jiridanek requested GitHub issue creation for OpenShift client architecture mapping problem affecting 29 Dockerfiles during PR #1320 review. Issue was created with comprehensive analysis covering all affected files using $(uname -m) returning 'aarch64' but OpenShift mirror expecting 'arm64', systematic solution using BuildKit TARGETARCH mapping with proper amd64→x86_64 and arm64→arm64 conversion, detailed acceptance criteria, and implementation guidance, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/tensorflow/ubi9-python-3.12/Dockerfile.cuda:38-38
Timestamp: 2025-07-08T19:30:20.513Z
Learning: jiridanek requested GitHub issue creation for multi-architecture support in TensorFlow CUDA runtime image during PR #1333 review. Issue was created with comprehensive problem description covering hardcoded NVARCH limitation, multiple solution options using TARGETARCH build argument with architecture mapping, acceptance criteria for multi-architecture builds, implementation guidance with code examples, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: jupyter/minimal/ubi9-python-3.11/Dockerfile.cuda:29-38
Timestamp: 2025-07-04T17:07:52.656Z
Learning: In the opendatahub-io/notebooks repository, modern Docker with BuildKit automatically provides build arguments like TARGETARCH in the global scope for FROM instructions, but these arguments must be explicitly declared with ARG statements inside build stages where they will be used. The ARG declaration should be placed within the stage that uses it, not moved to the global scope, as this is the correct pattern for modern Docker/Podman/Buildah environments.
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: rstudio/rhel9-python-3.11/Dockerfile.cuda:40-42
Timestamp: 2025-07-04T17:08:02.399Z
Learning: In the opendatahub-io/notebooks repository, when using multi-architecture Dockerfiles with BuildKit, the implicit build argument TARGETARCH is automatically available in the global scope for FROM instructions without explicit declaration. However, if TARGETARCH is used within a build stage, it must be declared explicitly within that stage. The current placement pattern (declaring ARG TARGETARCH after FROM instructions that use it) is correct for modern Docker/Podman/Buildah environments and does not require compatibility with older Docker versions.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-01T10:41:56.419Z
Learning: jiridanek's team uses containerized dependency locking for cross-platform compatibility in opendatahub-io/notebooks. They run `pipenv lock` inside UBI9 containers with specific platform arguments (`--platform=linux/amd64 --python-version 3.12`) to avoid host OS dependency conflicts when generating Pipfile.lock files.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1306
File: jupyter/trustyai/ubi9-python-3.12/Dockerfile.cpu:4-4
Timestamp: 2025-07-04T05:49:10.314Z
Learning: jiridanek directs base image pinning security concerns to existing comprehensive issue #1242 "Improve Docker FROM image versioning by avoiding :latest tags" rather than addressing them in individual PRs, continuing the established pattern of systematic security and quality tracking in opendatahub-io/notebooks.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-01T10:41:56.419Z
Learning: In the opendatahub-io/notebooks repository, TensorFlow packages with `extras = ["and-cuda"]` can cause build conflicts on macOS due to platform-specific CUDA packages. When the Dockerfile installs CUDA system-wide, removing the extras and letting TensorFlow find CUDA at runtime resolves these conflicts.
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: rstudio/rhel9-python-3.11/Dockerfile.cuda:34-35
Timestamp: 2025-07-04T10:41:13.061Z
Learning: In the opendatahub-io/notebooks repository, when adapting NVIDIA CUDA Dockerfiles, the project intentionally maintains consistency with upstream NVIDIA patterns even when it might involve potential risks like empty variable expansions in package installation commands. This is considered acceptable because the containers only run on RHEL 9 with known yum/dnf behavior, and upstream consistency is prioritized over defensive coding practices.
jupyter/minimal/ubi9-python-3.12/Dockerfile.cpu (12)
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1306
File: jupyter/trustyai/ubi9-python-3.12/Dockerfile.cpu:135-136
Timestamp: 2025-07-04T05:52:49.464Z
Learning: jiridanek requested GitHub issue creation for improving fragile sed-based Jupyter kernel display_name modification in jupyter/trustyai/ubi9-python-3.12/Dockerfile.cpu during PR #1306 review. Issue #1321 was created with comprehensive problem description covering JSON corruption risks, greedy regex patterns, maintenance burden, and proposed Python-based JSON parsing solution with detailed acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements.
Learnt from: atheo89
PR: opendatahub-io/notebooks#1258
File: codeserver/ubi9-python-3.11/Dockerfile.cpu:32-32
Timestamp: 2025-07-07T11:08:48.524Z
Learning: atheo89 requested GitHub issue creation for multi-architecture Dockerfile improvements during PR #1258 review, specifically for enhancing structural consistency across Docker stages, replacing $(uname -m) with ${TARGETARCH} for cross-architecture builds, and adding OCI-compliant metadata labels. Issue #1332 was created with comprehensive problem description, phased implementation approach, detailed acceptance criteria, implementation guidance with code examples, and proper context linking, continuing the established pattern of systematic code quality improvements.
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: rstudio/rhel9-python-3.11/Dockerfile.cuda:34-35
Timestamp: 2025-07-04T10:41:13.061Z
Learning: In the opendatahub-io/notebooks repository, when adapting NVIDIA CUDA Dockerfiles, the project intentionally maintains consistency with upstream NVIDIA patterns even when it might involve potential risks like empty variable expansions in package installation commands. This is considered acceptable because the containers only run on RHEL 9 with known yum/dnf behavior, and upstream consistency is prioritized over defensive coding practices.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-09T10:24:37.290Z
Learning: jiridanek requested GitHub issue creation for TeX Live installation robustness improvements in jupyter/utils/install_pdf_deps.sh during PR #1357 review, specifically for network resilience and error handling improvements to address flaky CI failures. Issue was created with comprehensive problem description covering network download failures, mirror fallback mechanisms, retry logic, caching strategies, multiple solution options with code examples, detailed acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1260
File: jupyter/utils/install_pdf_deps.sh:13-27
Timestamp: 2025-07-03T13:04:11.835Z
Learning: jiridanek requested GitHub issue creation for investigating alternatives to directory move operation in install_pdf_deps.sh during PR #1260 review, specifically to explore cleaner architectural approaches like installing TeX Live directly to /usr/local/texlive/bin instead of using filesystem manipulation post-installation.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1260
File: jupyter/utils/install_pdf_deps.sh:13-27
Timestamp: 2025-07-03T13:04:11.835Z
Learning: jiridanek requested GitHub issue creation for investigating alternatives to directory move operation in install_pdf_deps.sh during PR #1260 review, specifically to explore cleaner architectural approaches like installing TeX Live directly to /usr/local/texlive/bin instead of using filesystem manipulation post-installation. Issue #1291 was created with comprehensive problem description, multiple solution options, acceptance criteria, and proper context linking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-09T10:24:37.290Z
Learning: jiridanek requested GitHub issue creation for TeX Live installation robustness improvements in jupyter/utils/install_pdf_deps.sh during PR #1357 review, specifically for network resilience and error handling improvements to address flaky CI failures. Issue #1361 was successfully created with comprehensive problem description covering network download failures, mirror fallback mechanisms, retry logic, caching strategies, multiple solution options with code examples, detailed acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1306
File: jupyter/trustyai/ubi9-python-3.12/kustomize/base/kustomization.yaml:8-12
Timestamp: 2025-07-08T19:09:48.746Z
Learning: jiridanek requested GitHub issue creation for misleading CUDA prefix in TrustyAI image tags during PR #1306 review, affecting both Python 3.11 and 3.12 versions. Issue #1338 was created with comprehensive problem description covering both affected images, repository pattern analysis comparing correct vs incorrect naming conventions, clear solution with code examples, detailed acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: rstudio/rhel9-python-3.11/Dockerfile.cuda:40-42
Timestamp: 2025-07-04T17:08:02.399Z
Learning: In the opendatahub-io/notebooks repository, when using multi-architecture Dockerfiles with BuildKit, the implicit build argument TARGETARCH is automatically available in the global scope for FROM instructions without explicit declaration. However, if TARGETARCH is used within a build stage, it must be declared explicitly within that stage. The current placement pattern (declaring ARG TARGETARCH after FROM instructions that use it) is correct for modern Docker/Podman/Buildah environments and does not require compatibility with older Docker versions.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-pytorch/ubi9-python-3.12/de-vendor-torch.sh:9-12
Timestamp: 2025-07-08T19:28:15.791Z
Learning: jiridanek requested GitHub issue creation for runtime detection improvement of Python site-packages paths during PR #1333 review. Issue #1344 was created with comprehensive problem description covering hard-coded path fragility across UBI9 distributions, extensive affected files analysis including 4 de-vendor scripts, 30+ Dockerfiles with chmod operations, and 12+ pip.conf configurations, runtime detection solution using sysconfig module, implementation areas breakdown, benefits analysis, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: jupyter/minimal/ubi9-python-3.11/Dockerfile.cuda:29-38
Timestamp: 2025-07-04T17:07:52.656Z
Learning: In the opendatahub-io/notebooks repository, modern Docker with BuildKit automatically provides build arguments like TARGETARCH in the global scope for FROM instructions, but these arguments must be explicitly declared with ARG statements inside build stages where they will be used. The ARG declaration should be placed within the stage that uses it, not moved to the global scope, as this is the correct pattern for modern Docker/Podman/Buildah environments.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-01T10:41:56.419Z
Learning: jiridanek's team uses containerized dependency locking for cross-platform compatibility in opendatahub-io/notebooks. They run `pipenv lock` inside UBI9 containers with specific platform arguments (`--platform=linux/amd64 --python-version 3.12`) to avoid host OS dependency conflicts when generating Pipfile.lock files.
Signed-off-by: puneetsharma21 <[email protected]>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (1)
jupyter/utils/install_pandoc.sh (1)
43-49: Add version check and expose pandoc on PATH for amd64 installation
The amd64 branch unpacks Pandoc but never verifies the binary or makes it accessible via the default$PATH, unlike the ppc64le block. Let’s mirror the sanity check and expose step to catch extraction errors early and ensurepandocis on the path.• File:
jupyter/utils/install_pandoc.sh
• Location: under theelif [[ "$ARCH" == "amd64" ]]; thenblock (around lines 43–49)tar xvzf /tmp/pandoc.tar.gz --strip-components 1 -C /usr/local/pandoc/ rm -f /tmp/pandoc.tar.gz + + # Expose pandoc on PATH and verify installation + ln -sf /usr/local/pandoc/bin/pandoc /usr/local/bin/pandoc + /usr/local/pandoc/bin/pandoc --version
🧹 Nitpick comments (4)
jupyter/utils/install_texlive.sh (2)
16-20: Trim image size & network traffic by cleaning package cache and removing artefacts
dnf install -y …leaves the /var/cache/dnf layer (~150 MB) and the two
tarballs behind. Add explicit cleanup to keep the final image lean:dnf install -y gcc-toolset-13 perl make libX11-devel libXt-devel \ zlib-devel freetype-devel libpng-devel ncurses-devel \ gd-devel libtool wget tar xz bison flex libXaw-devel +dnf clean all && rm -rf /var/cache/dnf … -rm -rf /texlive-20250308-source /texlive-build +rm -rf /texlive-20250308-source /texlive-build \ + texlive-20250308-source.tar.xz install-tl-unx.tar.gzAlso applies to: 40-41
78-79: Minor style nit – usetar -xzfdirectlyUsing
zcat | tar xf -is functionally fine but slower and less readable. A
singletar -xzf install-tl-unx.tar.gzsuffices.jupyter/utils/install_pandoc.sh (2)
4-12: Mapping definesarm64&s390xbut immediately rejects them
UNAME_TO_GOARCHadvertises support foraarch64→arm64ands390x, yet the case-statement only handlesppc64leandamd64, so those two archs fall through to “unsupported”. Either:
- drop them from the map, or
- add proper branches (even a TODO stub) so the intent is explicit.
Leaving dead code confuses readers and automation alike.
Also applies to: 50-52
37-38:rm -rf ~/.cabal ~/.ghcmay wipe host-mounted caches
If the script ever runs in a container with a volume-mounted home (CI cache), this line deletes the cache instead of leveraging it. Consider restricting the cleanup to the build container layer (/root/.cabal&/root/.ghc) or providing a knob to skip it.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
jupyter/minimal/ubi9-python-3.11/Dockerfile.cpu(3 hunks)jupyter/minimal/ubi9-python-3.12/Dockerfile.cpu(2 hunks)jupyter/utils/install_pandoc.sh(1 hunks)jupyter/utils/install_texlive.sh(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- jupyter/minimal/ubi9-python-3.11/Dockerfile.cpu
- jupyter/minimal/ubi9-python-3.12/Dockerfile.cpu
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-09T10:24:37.290Z
Learning: jiridanek requested GitHub issue creation for TeX Live installation robustness improvements in jupyter/utils/install_pdf_deps.sh during PR #1357 review, specifically for network resilience and error handling improvements to address flaky CI failures. Issue was created with comprehensive problem description covering network download failures, mirror fallback mechanisms, retry logic, caching strategies, multiple solution options with code examples, detailed acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-09T10:24:37.290Z
Learning: jiridanek requested GitHub issue creation for TeX Live installation robustness improvements in jupyter/utils/install_pdf_deps.sh during PR #1357 review, specifically for network resilience and error handling improvements to address flaky CI failures. Issue #1361 was successfully created with comprehensive problem description covering network download failures, mirror fallback mechanisms, retry logic, caching strategies, multiple solution options with code examples, detailed acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1260
File: jupyter/utils/install_pdf_deps.sh:13-27
Timestamp: 2025-07-03T13:04:11.835Z
Learning: jiridanek requested GitHub issue creation for investigating alternatives to directory move operation in install_pdf_deps.sh during PR #1260 review, specifically to explore cleaner architectural approaches like installing TeX Live directly to /usr/local/texlive/bin instead of using filesystem manipulation post-installation. Issue #1291 was created with comprehensive problem description, multiple solution options, acceptance criteria, and proper context linking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1260
File: jupyter/utils/install_pdf_deps.sh:13-27
Timestamp: 2025-07-03T13:04:11.835Z
Learning: jiridanek requested GitHub issue creation for investigating alternatives to directory move operation in install_pdf_deps.sh during PR #1260 review, specifically to explore cleaner architectural approaches like installing TeX Live directly to /usr/local/texlive/bin instead of using filesystem manipulation post-installation.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-11T11:16:05.131Z
Learning: jiridanek requested GitHub issue creation for RStudio py311 Tekton push pipelines during PR #1379 review. Issue #1384 was successfully created covering two RStudio variants (CPU and CUDA) found in manifests/base/params-latest.env, with comprehensive problem description, implementation requirements following the same pattern as other workbench pipelines, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-11T11:16:05.131Z
Learning: jiridanek requested GitHub issue creation for adding RStudio py311 Tekton push pipelines during PR #1379 review, referencing existing registry entries in manifests/base/params-latest.env but missing corresponding .tekton pipeline files. A comprehensive issue was created with detailed problem description, implementation requirements following the same pattern as other workbench pipelines, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-tensorflow/ubi9-python-3.12/Dockerfile.rocm:50-50
Timestamp: 2025-07-08T19:30:01.738Z
Learning: jiridanek requested GitHub issue creation for multi-architecture support in ROCm TensorFlow image during PR #1333 review. Issue #1346 was created with comprehensive problem description covering hardcoded x86_64 architecture breaking multi-arch support, detailed impact analysis, three solution options (runtime detection, BuildKit TARGETARCH integration, hybrid approach) with pros/cons analysis, comprehensive acceptance criteria covering core requirements and testing, phased implementation guidance, related files identification, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: jupyter/pytorch/ubi9-python-3.12/Dockerfile.cuda:65-66
Timestamp: 2025-07-09T12:31:02.033Z
Learning: jiridanek requested GitHub issue creation for MSSQL repo file hardcoding problem during PR #1320 review. Issue #1363 was created and updated with comprehensive problem description covering hardcoded x86_64 MSSQL repo files breaking multi-architecture builds across 10 affected Dockerfiles (including datascience, CUDA, ROCm, and TrustyAI variants), detailed root cause analysis, three solution options with code examples, clear acceptance criteria for all image types, implementation guidance following established multi-architecture patterns, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: jupyter/pytorch/ubi9-python-3.12/Dockerfile.cuda:42-52
Timestamp: 2025-07-09T12:29:56.162Z
Learning: jiridanek requested GitHub issue creation for OpenShift client architecture mapping problem affecting 29 Dockerfiles during PR #1320 review. Issue was created with comprehensive analysis covering all affected files using $(uname -m) returning 'aarch64' but OpenShift mirror expecting 'arm64', systematic solution using BuildKit TARGETARCH mapping with proper amd64→x86_64 and arm64→arm64 conversion, detailed acceptance criteria, and implementation guidance, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:02:13.228Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. The automated issue creation failed despite appearing successful, so comprehensive issue content was provided for manual creation covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: jupyter/minimal/ubi9-python-3.11/Dockerfile.cuda:29-38
Timestamp: 2025-07-04T17:07:52.656Z
Learning: In the opendatahub-io/notebooks repository, modern Docker with BuildKit automatically provides build arguments like TARGETARCH in the global scope for FROM instructions, but these arguments must be explicitly declared with ARG statements inside build stages where they will be used. The ARG declaration should be placed within the stage that uses it, not moved to the global scope, as this is the correct pattern for modern Docker/Podman/Buildah environments.
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: rstudio/rhel9-python-3.11/Dockerfile.cuda:40-42
Timestamp: 2025-07-04T17:08:02.399Z
Learning: In the opendatahub-io/notebooks repository, when using multi-architecture Dockerfiles with BuildKit, the implicit build argument TARGETARCH is automatically available in the global scope for FROM instructions without explicit declaration. However, if TARGETARCH is used within a build stage, it must be declared explicitly within that stage. The current placement pattern (declaring ARG TARGETARCH after FROM instructions that use it) is correct for modern Docker/Podman/Buildah environments and does not require compatibility with older Docker versions.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-01T10:41:56.419Z
Learning: jiridanek's team uses containerized dependency locking for cross-platform compatibility in opendatahub-io/notebooks. They run `pipenv lock` inside UBI9 containers with specific platform arguments (`--platform=linux/amd64 --python-version 3.12`) to avoid host OS dependency conflicts when generating Pipfile.lock files.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1306
File: jupyter/trustyai/ubi9-python-3.12/Dockerfile.cpu:4-4
Timestamp: 2025-07-04T05:49:10.314Z
Learning: jiridanek directs base image pinning security concerns to existing comprehensive issue #1242 "Improve Docker FROM image versioning by avoiding :latest tags" rather than addressing them in individual PRs, continuing the established pattern of systematic security and quality tracking in opendatahub-io/notebooks.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-01T10:41:56.419Z
Learning: In the opendatahub-io/notebooks repository, TensorFlow packages with `extras = ["and-cuda"]` can cause build conflicts on macOS due to platform-specific CUDA packages. When the Dockerfile installs CUDA system-wide, removing the extras and letting TensorFlow find CUDA at runtime resolves these conflicts.
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: rstudio/rhel9-python-3.11/Dockerfile.cuda:34-35
Timestamp: 2025-07-04T10:41:13.061Z
Learning: In the opendatahub-io/notebooks repository, when adapting NVIDIA CUDA Dockerfiles, the project intentionally maintains consistency with upstream NVIDIA patterns even when it might involve potential risks like empty variable expansions in package installation commands. This is considered acceptable because the containers only run on RHEL 9 with known yum/dnf behavior, and upstream consistency is prioritized over defensive coding practices.
jupyter/utils/install_pandoc.sh (24)
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:02:13.228Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. The automated issue creation failed despite appearing successful, so comprehensive issue content was provided for manual creation covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-09T10:24:37.290Z
Learning: jiridanek requested GitHub issue creation for TeX Live installation robustness improvements in jupyter/utils/install_pdf_deps.sh during PR #1357 review, specifically for network resilience and error handling improvements to address flaky CI failures. Issue was created with comprehensive problem description covering network download failures, mirror fallback mechanisms, retry logic, caching strategies, multiple solution options with code examples, detailed acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-09T10:24:37.290Z
Learning: jiridanek requested GitHub issue creation for TeX Live installation robustness improvements in jupyter/utils/install_pdf_deps.sh during PR #1357 review, specifically for network resilience and error handling improvements to address flaky CI failures. Issue #1361 was successfully created with comprehensive problem description covering network download failures, mirror fallback mechanisms, retry logic, caching strategies, multiple solution options with code examples, detailed acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-03T14:04:05.280Z
Learning: In opendatahub-io/notebooks, shell scripting robustness and efficiency issues in extension management loops (such as unquoted globs, word-splitting, and unnecessary repeated copies in run-code-server.sh) are systematically tracked and fixed by quoting variables, using `cp -a --`, and toggling `nullglob`, following the established pattern of operational correctness improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:02:13.228Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. Issue #1364 was created with comprehensive problem description covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1260
File: jupyter/utils/install_pdf_deps.sh:13-27
Timestamp: 2025-07-03T13:04:11.835Z
Learning: jiridanek requested GitHub issue creation for investigating alternatives to directory move operation in install_pdf_deps.sh during PR #1260 review, specifically to explore cleaner architectural approaches like installing TeX Live directly to /usr/local/texlive/bin instead of using filesystem manipulation post-installation. Issue #1291 was created with comprehensive problem description, multiple solution options, acceptance criteria, and proper context linking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:02:13.228Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. Issue was created with comprehensive problem description covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:02:13.228Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. Issue was created with comprehensive problem description covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:02:13.228Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. Issue was created with comprehensive problem description covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:02:13.228Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. Issue was created with comprehensive problem description covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:39:23.433Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. Issue #1373 was successfully created on the second attempt with comprehensive problem description covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: atheo89
PR: opendatahub-io/notebooks#1258
File: codeserver/ubi9-python-3.11/Dockerfile.cpu:32-32
Timestamp: 2025-07-07T11:08:48.524Z
Learning: atheo89 requested GitHub issue creation for multi-architecture Dockerfile improvements during PR #1258 review, specifically for enhancing structural consistency across Docker stages, replacing $(uname -m) with ${TARGETARCH} for cross-architecture builds, and adding OCI-compliant metadata labels. Issue #1332 was created with comprehensive problem description, phased implementation approach, detailed acceptance criteria, implementation guidance with code examples, and proper context linking, continuing the established pattern of systematic code quality improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-tensorflow/ubi9-python-3.12/Dockerfile.rocm:50-50
Timestamp: 2025-07-08T19:30:01.738Z
Learning: jiridanek requested GitHub issue creation for multi-architecture support in ROCm TensorFlow image during PR #1333 review. Issue #1346 was created with comprehensive problem description covering hardcoded x86_64 architecture breaking multi-arch support, detailed impact analysis, three solution options (runtime detection, BuildKit TARGETARCH integration, hybrid approach) with pros/cons analysis, comprehensive acceptance criteria covering core requirements and testing, phased implementation guidance, related files identification, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: jupyter/pytorch/ubi9-python-3.12/Dockerfile.cuda:42-52
Timestamp: 2025-07-09T12:29:56.162Z
Learning: jiridanek requested GitHub issue creation for OpenShift client architecture mapping problem affecting 29 Dockerfiles during PR #1320 review. Issue was created with comprehensive analysis covering all affected files using $(uname -m) returning 'aarch64' but OpenShift mirror expecting 'arm64', systematic solution using BuildKit TARGETARCH mapping with proper amd64→x86_64 and arm64→arm64 conversion, detailed acceptance criteria, and implementation guidance, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1260
File: jupyter/utils/install_pdf_deps.sh:13-27
Timestamp: 2025-07-03T13:04:11.835Z
Learning: jiridanek requested GitHub issue creation for investigating alternatives to directory move operation in install_pdf_deps.sh during PR #1260 review, specifically to explore cleaner architectural approaches like installing TeX Live directly to /usr/local/texlive/bin instead of using filesystem manipulation post-installation.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/run-code-server.sh:17-17
Timestamp: 2025-07-03T12:26:24.084Z
Learning: jiridanek requests GitHub issue creation for shell script quality improvements identified during PR #1269 review, specifically for unquoted command substitution in codeserver/ubi9-python-3.12/run-code-server.sh. Issue #1283 was created with comprehensive problem descriptions, acceptance criteria, implementation guidance, and proper context linking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/run-nginx.sh:18-23
Timestamp: 2025-07-03T16:17:23.065Z
Learning: jiridanek requested GitHub issue creation for shell script variable quoting security concern in codeserver/ubi9-python-3.12/run-nginx.sh during PR #1269 review. The issue covers unquoted variables NB_PREFIX, NOTEBOOK_ARGS, and BASE_URL that pose security risks including command injection, word-splitting vulnerabilities, and globbing issues. A comprehensive issue was created with detailed problem description, security concerns, solution with code examples, acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/run-nginx.sh:23-23
Timestamp: 2025-07-03T12:29:24.067Z
Learning: jiridanek requested GitHub issue creation for shell script safety improvement in codeserver/ubi9-python-3.12/run-nginx.sh during PR #1269 review, specifically for replacing unsafe in-place file modification with tee. Issue #1285 was created with comprehensive problem descriptions, risk assessment, recommended atomic file operations solution, acceptance criteria, and proper context linking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/nginx/root/usr/share/container-scripts/nginx/common.sh:4-11
Timestamp: 2025-07-03T12:08:47.691Z
Learning: jiridanek requests GitHub issue creation for shell script quality improvements identified during PR #1269 review, specifically for POSIX compliance and security issues in codeserver/ubi9-python-3.12/nginx/root/usr/share/container-scripts/nginx/common.sh. Issue #1275 was created with comprehensive problem descriptions, acceptance criteria, implementation guidance, and proper context linking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/nginx/root/opt/app-root/etc/generate_container_user:4-9
Timestamp: 2025-07-03T16:05:35.448Z
Learning: jiridanek requested GitHub issue creation for shell script error handling improvements in codeserver/ubi9-python-3.12/nginx/root/opt/app-root/etc/generate_container_user during PR #1269 review. A comprehensive issue was created covering silent failures, unquoted variable expansions, missing template validation, and strict mode implementation with detailed problem descriptions, phased acceptance criteria, implementation guidance with code examples, and proper context linking, continuing the established pattern of systematic code quality improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-pytorch/ubi9-python-3.12/de-vendor-torch.sh:9-12
Timestamp: 2025-07-08T19:28:15.791Z
Learning: jiridanek requested GitHub issue creation for runtime detection improvement of Python site-packages paths during PR #1333 review. Issue #1344 was created with comprehensive problem description covering hard-coded path fragility across UBI9 distributions, extensive affected files analysis including 4 de-vendor scripts, 30+ Dockerfiles with chmod operations, and 12+ pip.conf configurations, runtime detection solution using sysconfig module, implementation areas breakdown, benefits analysis, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/run-code-server.sh:5-5
Timestamp: 2025-07-03T12:25:26.453Z
Learning: jiridanek requested GitHub issue creation for shell script safety improvements identified during PR #1269 review, specifically for unsafe globbing patterns in codeserver/ubi9-python-3.12/run-code-server.sh. Issue #1281 was created with comprehensive problem descriptions, solution options, acceptance criteria, and proper context linking, following the established pattern for systematic tracking of technical improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/run-code-server.sh:20-40
Timestamp: 2025-07-03T12:27:09.739Z
Learning: jiridanek requested GitHub issue creation for shell script error handling improvements in codeserver/ubi9-python-3.12/run-code-server.sh create_dir_and_file function during PR #1269 review. Issue #1284 was created with comprehensive problem description, acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/utils/process.sh:1-2
Timestamp: 2025-07-03T16:00:46.191Z
Learning: jiridanek requested GitHub issue creation for shell script strict-mode improvement in codeserver/ubi9-python-3.12/utils/process.sh during PR #1269 review. Issue #1303 was created with comprehensive problem description covering silent failures and production risks, phased acceptance criteria for basic strict-mode implementation and enhanced error handling, implementation guidance with code examples and flag explanations, benefits section, and proper context linking, continuing the established pattern of systematic code quality improvements.
jupyter/utils/install_texlive.sh (18)
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-09T10:24:37.290Z
Learning: jiridanek requested GitHub issue creation for TeX Live installation robustness improvements in jupyter/utils/install_pdf_deps.sh during PR #1357 review, specifically for network resilience and error handling improvements to address flaky CI failures. Issue was created with comprehensive problem description covering network download failures, mirror fallback mechanisms, retry logic, caching strategies, multiple solution options with code examples, detailed acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1260
File: jupyter/utils/install_pdf_deps.sh:13-27
Timestamp: 2025-07-03T13:04:11.835Z
Learning: jiridanek requested GitHub issue creation for investigating alternatives to directory move operation in install_pdf_deps.sh during PR #1260 review, specifically to explore cleaner architectural approaches like installing TeX Live directly to /usr/local/texlive/bin instead of using filesystem manipulation post-installation. Issue #1291 was created with comprehensive problem description, multiple solution options, acceptance criteria, and proper context linking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1260
File: jupyter/utils/install_pdf_deps.sh:13-27
Timestamp: 2025-07-03T13:04:11.835Z
Learning: jiridanek requested GitHub issue creation for investigating alternatives to directory move operation in install_pdf_deps.sh during PR #1260 review, specifically to explore cleaner architectural approaches like installing TeX Live directly to /usr/local/texlive/bin instead of using filesystem manipulation post-installation.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-09T10:24:37.290Z
Learning: jiridanek requested GitHub issue creation for TeX Live installation robustness improvements in jupyter/utils/install_pdf_deps.sh during PR #1357 review, specifically for network resilience and error handling improvements to address flaky CI failures. Issue #1361 was successfully created with comprehensive problem description covering network download failures, mirror fallback mechanisms, retry logic, caching strategies, multiple solution options with code examples, detailed acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-03T14:04:05.280Z
Learning: In opendatahub-io/notebooks, shell scripting robustness and efficiency issues in extension management loops (such as unquoted globs, word-splitting, and unnecessary repeated copies in run-code-server.sh) are systematically tracked and fixed by quoting variables, using `cp -a --`, and toggling `nullglob`, following the established pattern of operational correctness improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/utils/process.sh:1-2
Timestamp: 2025-07-03T16:00:46.191Z
Learning: jiridanek requested GitHub issue creation for shell script strict-mode improvement in codeserver/ubi9-python-3.12/utils/process.sh during PR #1269 review. Issue #1303 was created with comprehensive problem description covering silent failures and production risks, phased acceptance criteria for basic strict-mode implementation and enhanced error handling, implementation guidance with code examples and flag explanations, benefits section, and proper context linking, continuing the established pattern of systematic code quality improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/run-code-server.sh:17-17
Timestamp: 2025-07-03T12:26:24.084Z
Learning: jiridanek requests GitHub issue creation for shell script quality improvements identified during PR #1269 review, specifically for unquoted command substitution in codeserver/ubi9-python-3.12/run-code-server.sh. Issue #1283 was created with comprehensive problem descriptions, acceptance criteria, implementation guidance, and proper context linking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/run-code-server.sh:20-40
Timestamp: 2025-07-03T12:27:09.739Z
Learning: jiridanek requested GitHub issue creation for shell script error handling improvements in codeserver/ubi9-python-3.12/run-code-server.sh create_dir_and_file function during PR #1269 review. Issue #1284 was created with comprehensive problem description, acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:02:13.228Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. The automated issue creation failed despite appearing successful, so comprehensive issue content was provided for manual creation covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:02:13.228Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. Issue #1364 was created with comprehensive problem description covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:02:13.228Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. Issue was created with comprehensive problem description covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:02:13.228Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. Issue was created with comprehensive problem description covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:02:13.228Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. Issue was created with comprehensive problem description covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:02:13.228Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. Issue was created with comprehensive problem description covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:39:23.433Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. Issue #1373 was successfully created on the second attempt with comprehensive problem description covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: atheo89
PR: opendatahub-io/notebooks#1258
File: codeserver/ubi9-python-3.11/Dockerfile.cpu:32-32
Timestamp: 2025-07-07T11:08:48.524Z
Learning: atheo89 requested GitHub issue creation for multi-architecture Dockerfile improvements during PR #1258 review, specifically for enhancing structural consistency across Docker stages, replacing $(uname -m) with ${TARGETARCH} for cross-architecture builds, and adding OCI-compliant metadata labels. Issue #1332 was created with comprehensive problem description, phased implementation approach, detailed acceptance criteria, implementation guidance with code examples, and proper context linking, continuing the established pattern of systematic code quality improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-tensorflow/ubi9-python-3.12/Dockerfile.rocm:50-50
Timestamp: 2025-07-08T19:30:01.738Z
Learning: jiridanek requested GitHub issue creation for multi-architecture support in ROCm TensorFlow image during PR #1333 review. Issue #1346 was created with comprehensive problem description covering hardcoded x86_64 architecture breaking multi-arch support, detailed impact analysis, three solution options (runtime detection, BuildKit TARGETARCH integration, hybrid approach) with pros/cons analysis, comprehensive acceptance criteria covering core requirements and testing, phased implementation guidance, related files identification, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: rstudio/rhel9-python-3.11/Dockerfile.cuda:40-42
Timestamp: 2025-07-04T17:08:02.399Z
Learning: In the opendatahub-io/notebooks repository, when using multi-architecture Dockerfiles with BuildKit, the implicit build argument TARGETARCH is automatically available in the global scope for FROM instructions without explicit declaration. However, if TARGETARCH is used within a build stage, it must be declared explicitly within that stage. The current placement pattern (declaring ARG TARGETARCH after FROM instructions that use it) is correct for modern Docker/Podman/Buildah environments and does not require compatibility with older Docker versions.
🔇 Additional comments (1)
jupyter/utils/install_texlive.sh (1)
28-28: Ensuregcc-toolset-13activation does not silently fail
source /opt/rh/gcc-toolset-13/enablewill exit the script if the file is
missing (because ofset -e). On UBI9 images the path is available only after
dnf install gcc-toolset-13, but in minimal images the SCL infrastructure may
be absent.Consider:
if [[ -f /opt/rh/gcc-toolset-13/enable ]]; then source /opt/rh/gcc-toolset-13/enable else echo "gcc-toolset-13 not found" >&2; exit 1 fi
Comment on lines
+81
to
+82
| mv /usr/local/texlive/bin/"$(uname -m)-linux" /usr/local/texlive/bin/linux | ||
| cd /usr/local/texlive/bin/linux |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Derive TeX Live binary dir dynamically instead of assuming $(uname -m)-linux
The installer names the bin dir <arch>-linux, but on future releases or
cross-builds that may differ. Fail-proof alternative:
-mv /usr/local/texlive/bin/"$(uname -m)-linux" /usr/local/texlive/bin/linux
+BIN_DIR=$(find /usr/local/texlive/bin -maxdepth 1 -type d -name '*-linux' | head -n1)
+mv "$BIN_DIR" /usr/local/texlive/bin/linux📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| mv /usr/local/texlive/bin/"$(uname -m)-linux" /usr/local/texlive/bin/linux | |
| cd /usr/local/texlive/bin/linux | |
| BIN_DIR=$(find /usr/local/texlive/bin -maxdepth 1 -type d -name '*-linux' | head -n1) | |
| mv "$BIN_DIR" /usr/local/texlive/bin/linux | |
| cd /usr/local/texlive/bin/linux |
🤖 Prompt for AI Agents
In jupyter/utils/install_texlive.sh around lines 81 to 82, the script assumes
the TeX Live binary directory is named using the pattern "$(uname -m)-linux",
which may not hold true for future releases or cross-builds. Modify the script
to dynamically determine the actual TeX Live binary directory name instead of
hardcoding it. This can be done by listing the directories under
/usr/local/texlive/bin and selecting the appropriate one programmatically before
moving and changing into it.
There was a problem hiding this comment.
isn't this overly complicated?
There was a problem hiding this comment.
@jiridanek You're absolutely right! The current approach using $(uname -m)-linux is actually better. TeX Live has consistently used this naming pattern for years, and $(uname -m) reliably provides the correct architecture string.
My suggested find command adds unnecessary complexity and potential failure points (what if no directories match, or multiple match?). The existing code is simpler, more predictable, and follows the established TeX Live convention.
Thanks for the reality check - sometimes the straightforward solution is the right one.
There was a problem hiding this comment.
@coderabbitai create github issue as a reminder for me to revisit this discussion in a final once-over for all the ibm arches merging process
There was a problem hiding this comment.
🧩 Analysis chain
@jiridanek I've created a GitHub issue to track the TeX Live binary directory naming discussion for your final review during the IBM architectures merging process. The issue captures the key discussion points and provides a structured way to revisit this technical decision as part of your comprehensive review.
🏁 Script executed:
#!/bin/bash
# Create GitHub issue for TeX Live binary directory naming review
gh issue create \
--title "Review TeX Live binary directory naming approach for IBM architectures" \
--body "## Problem Description
During the review of PR #1179 (Add TeX Live and Pandoc installation for ppc64le), a discussion arose about the approach for handling TeX Live binary directory naming in \`jupyter/utils/install_texlive.sh\`.
## Context
The current implementation uses \`\$(uname -m)-linux\` pattern to identify and rename TeX Live binary directories:
\`\`\`bash
mv /usr/local/texlive/bin/\"\$(uname -m)-linux\" /usr/local/texlive/bin/linux
\`\`\`
An alternative dynamic discovery approach was initially suggested but deemed overly complicated after discussion.
## Discussion Points to Review
1. **Current approach**: Using \`\$(uname -m)-linux\` pattern
- Simple and follows established TeX Live conventions
- Reliable across architectures
2. **Alternative approach**: Dynamic directory discovery
- More complex with potential failure points
- May be unnecessary given TeX Live's consistent naming
## Action Items
- [ ] Review the TeX Live binary directory naming approach across all IBM architectures (ppc64le, s390x)
- [ ] Validate that the \`\$(uname -m)-linux\` pattern works consistently across all supported architectures
- [ ] Consider any edge cases or future compatibility concerns
- [ ] Document the final decision and rationale
## References
- **PR**: #1179
- **Comment**: https://github.com/opendatahub-io/notebooks/pull/1179#discussion_r2204425002
- **File**: \`jupyter/utils/install_texlive.sh\` lines 81-82
## Context
This review is part of the broader IBM architectures merging process and should be completed as part of the final once-over before merging architecture support changes." \
--assignee jiridanek
Length of output: 1800
@jiridanek Perfect! I've successfully created GitHub issue #2279 to track the TeX Live binary directory naming discussion for your final review during the IBM architectures merging process.
The issue captures:
- The technical discussion about
$(uname -m)-linuxvs dynamic discovery - Action items for validating the approach across IBM architectures
- Proper references to this PR and comment thread
- Context for the broader merging process
You can find it at: #2279
✏️ Learnings added
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1179
File: jupyter/utils/install_texlive.sh:80-81
Timestamp: 2025-09-05T07:27:28.332Z
Learning: jiridanek requested GitHub issue creation during PR #1179 review to track TeX Live binary directory naming approach discussion for final review during IBM architectures merging process, focusing on validating the $(uname -m)-linux pattern across all IBM architectures (ppc64le, s390x) rather than implementing dynamic discovery alternatives deemed overly complex.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1179
File: jupyter/utils/install_texlive.sh:80-81
Timestamp: 2025-09-05T07:27:28.332Z
Learning: jiridanek requested GitHub issue creation during PR #1179 review to track TeX Live binary directory naming approach discussion for final review during IBM architectures merging process, focusing on validating the $(uname -m)-linux pattern across all IBM architectures (ppc64le, s390x) rather than implementing dynamic discovery alternatives deemed overly complex. Issue #2279 was successfully created with comprehensive problem description, discussion points, action items, and proper context linking.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
🧠 Learnings used
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1260
File: jupyter/utils/install_pdf_deps.sh:13-27
Timestamp: 2025-07-03T13:04:11.835Z
Learning: jiridanek requested GitHub issue creation for investigating alternatives to directory move operation in install_pdf_deps.sh during PR #1260 review, specifically to explore cleaner architectural approaches like installing TeX Live directly to /usr/local/texlive/bin instead of using filesystem manipulation post-installation.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1260
File: jupyter/utils/install_pdf_deps.sh:13-27
Timestamp: 2025-07-03T13:04:11.835Z
Learning: jiridanek requested GitHub issue creation for investigating alternatives to directory move operation in install_pdf_deps.sh during PR #1260 review, specifically to explore cleaner architectural approaches like installing TeX Live directly to /usr/local/texlive/bin instead of using filesystem manipulation post-installation. Issue #1291 was created with comprehensive problem description, multiple solution options, acceptance criteria, and proper context linking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-09T10:24:37.290Z
Learning: jiridanek requested GitHub issue creation for TeX Live installation robustness improvements in jupyter/utils/install_pdf_deps.sh during PR #1357 review, specifically for network resilience and error handling improvements to address flaky CI failures. Issue was created with comprehensive problem description covering network download failures, mirror fallback mechanisms, retry logic, caching strategies, multiple solution options with code examples, detailed acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-09T10:24:37.290Z
Learning: jiridanek requested GitHub issue creation for TeX Live installation robustness improvements in jupyter/utils/install_pdf_deps.sh during PR #1357 review, specifically for network resilience and error handling improvements to address flaky CI failures. Issue #1361 was successfully created with comprehensive problem description covering network download failures, mirror fallback mechanisms, retry logic, caching strategies, multiple solution options with code examples, detailed acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: atheo89
PR: opendatahub-io/notebooks#1258
File: codeserver/ubi9-python-3.11/Dockerfile.cpu:32-32
Timestamp: 2025-07-07T11:08:48.524Z
Learning: atheo89 requested GitHub issue creation for multi-architecture Dockerfile improvements during PR #1258 review, specifically for enhancing structural consistency across Docker stages, replacing $(uname -m) with ${TARGETARCH} for cross-architecture builds, and adding OCI-compliant metadata labels. Issue #1332 was created with comprehensive problem description, phased implementation approach, detailed acceptance criteria, implementation guidance with code examples, and proper context linking, continuing the established pattern of systematic code quality improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:02:13.228Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. Issue was created with comprehensive problem description covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:02:13.228Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. Issue was created with comprehensive problem description covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:02:13.228Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. Issue was created with comprehensive problem description covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:02:13.228Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. Issue was created with comprehensive problem description covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: jupyter/pytorch/ubi9-python-3.12/Dockerfile.cuda:65-66
Timestamp: 2025-07-09T12:31:02.033Z
Learning: jiridanek requested GitHub issue creation for MSSQL repo file hardcoding problem during PR #1320 review. Issue #1363 was created and updated with comprehensive problem description covering hardcoded x86_64 MSSQL repo files breaking multi-architecture builds across 10 affected Dockerfiles (including datascience, CUDA, ROCm, and TrustyAI variants), detailed root cause analysis, three solution options with code examples, clear acceptance criteria for all image types, implementation guidance following established multi-architecture patterns, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2145
File: runtimes/rocm-tensorflow/ubi9-python-3.12/pyproject.toml:75-77
Timestamp: 2025-08-27T15:33:28.871Z
Learning: jiridanek requested GitHub issue creation for multi-architecture environment exploration during PR #2145 review, specifically to investigate architecture-specific environments for ROCm TensorFlow wheel optimization across x86_64, aarch64, ppc64le, and s390x architectures, noting uncertainty about implementation benefits but wanting systematic exploration through issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2145
File: runtimes/rocm-tensorflow/ubi9-python-3.12/pyproject.toml:75-77
Timestamp: 2025-08-27T15:33:28.871Z
Learning: jiridanek requested GitHub issue creation for multi-architecture environment exploration during PR #2145 review, specifically to investigate architecture-specific environments for ROCm TensorFlow wheel optimization across x86_64, aarch64, ppc64le, and s390x architectures, noting uncertainty about implementation benefits but wanting systematic exploration through issue tracking. Issue #2158 was created with comprehensive analysis covering current limitations, investigation areas, multiple solution options, and clear acceptance criteria.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-tensorflow/ubi9-python-3.12/Dockerfile.rocm:50-50
Timestamp: 2025-07-08T19:30:01.738Z
Learning: jiridanek requested GitHub issue creation for multi-architecture support in ROCm TensorFlow image during PR #1333 review. Issue #1346 was created with comprehensive problem description covering hardcoded x86_64 architecture breaking multi-arch support, detailed impact analysis, three solution options (runtime detection, BuildKit TARGETARCH integration, hybrid approach) with pros/cons analysis, comprehensive acceptance criteria covering core requirements and testing, phased implementation guidance, related files identification, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:39:23.433Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. Issue #1373 was successfully created on the second attempt with comprehensive problem description covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:02:13.228Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. The automated issue creation failed despite appearing successful, so comprehensive issue content was provided for manual creation covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2185
File: jupyter/pytorch/ubi9-python-3.12/Dockerfile.cuda:109-117
Timestamp: 2025-08-29T08:48:55.985Z
Learning: jiridanek prefers to implement systematic cleanup improvements through dedicated GitHub issues (like #2076) rather than applying individual point fixes during PR reviews, maintaining consistency with their established pattern of comprehensive code quality improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-08-05T17:24:08.616Z
Learning: jiridanek requested PR review for #1521 covering s390x architecture support improvements, demonstrating continued focus on systematic multi-architecture compatibility enhancements in the opendatahub-io/notebooks repository through clean implementation with centralized configuration, proper CI integration, and architecture-aware testing patterns.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-11T11:16:05.131Z
Learning: jiridanek requested GitHub issue creation for RStudio py311 Tekton push pipelines during PR #1379 review. Issue #1384 was successfully created covering two RStudio variants (CPU and CUDA) found in manifests/base/params-latest.env, with comprehensive problem description, implementation requirements following the same pattern as other workbench pipelines, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Pipfile:31-36
Timestamp: 2025-08-20T17:51:39.525Z
Learning: jiridanek consistently escalates point issues identified during PR reviews into systematic repository-wide improvements. When CodeRabbit flagged missing libxcrypt-compat in a single ROCm TensorFlow Python 3.12 image during PR #1259 review, jiridanek requested creation of issue #2075 for systematic review and fixing of all Python 3.12 UBI9 images, demonstrating his comprehensive approach to infrastructure consistency and code quality.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-11T11:16:05.131Z
Learning: jiridanek requested GitHub issue creation for adding RStudio py311 Tekton push pipelines during PR #1379 review, referencing existing registry entries in manifests/base/params-latest.env but missing corresponding .tekton pipeline files. A comprehensive issue was created with detailed problem description, implementation requirements following the same pattern as other workbench pipelines, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Signed-off-by: puneetsharma21 <[email protected]>
|
/ok-to-test |
|
@puneetsharma21: The following test failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
atheo89
pushed a commit
to atheo89/notebooks
that referenced
this pull request
Jul 23, 2025
…flux/component-updates/component-update-odh-pipeline-runtime-datascience-cpu-py311-ubi9-n-v2-24 Update odh-pipeline-runtime-datascience-cpu-py311-ubi9-n-v2-24 to 927a851
|
/build-konflux |
|
PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
4 tasks
jiridanek
reviewed
Sep 5, 2025
There was a problem hiding this comment.
@coderabbitai create a github issue to explore installing pandoc from epel, because epel is acceptable (as opposed to centos stream, which is not acceptable in red-hat-data-services/notebooks)
# Install pandoc
dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
dnf install -y pandoc
There was a problem hiding this comment.
🧩 Analysis chain
@jiridanek, I've created a comprehensive GitHub issue to explore installing Pandoc from EPEL repository for ppc64le architecture as requested. The issue systematically covers:
- Problem analysis of the current source-build approach vs EPEL packages
- Investigation areas including version comparison and architecture support
- Multiple solution options from pure EPEL to hybrid approaches
- Clear acceptance criteria for validation and testing
- Proper context linking back to this PR and discussion
This aligns with your established pattern of creating systematic issues for infrastructure improvements rather than implementing point fixes during PR reviews.
🏁 Script executed:
#!/bin/bash
# First, let's check what version of pandoc is available in EPEL for ppc64le
# and gather information about the current implementation
# Check the current pandoc version being installed from source
echo "Current pandoc version in install_pandoc.sh:"
grep -n "PANDOC_VERSION" jupyter/utils/install_pandoc.sh
# Let's also check if there are any existing issues related to pandoc or EPEL
echo -e "\n=== Searching for existing pandoc-related issues ==="
gh issue list --search "pandoc" --state=all --limit=10
echo -e "\n=== Searching for existing EPEL-related issues ==="
gh issue list --search "epel" --state=all --limit=10
Length of output: 1395
🏁 Script executed:
#!/bin/bash
# Create GitHub issue for exploring EPEL pandoc installation
gh issue create \
--title "Explore installing Pandoc from EPEL repository for ppc64le architecture" \
--body "## Problem Description
Currently, PR #1179 implements Pandoc installation for ppc64le architecture by building from source using the Haskell toolchain (cabal-install, ghc, gmp-devel). This approach:
- Requires significant build dependencies and compilation time
- Increases Docker build complexity and image size during build
- May face reliability issues in CI/CD environments with QEMU emulation
## Proposed Investigation
Explore using EPEL repository packages for Pandoc installation on ppc64le architecture as an alternative to building from source.
### Current Implementation (PR #1179)
- Builds Pandoc 3.7.0.2 from source using Haskell toolchain
- Requires: cabal-install, ghc, gmp-devel
- Build time: significant compilation overhead
- Final binary location: \`/usr/local/pandoc/bin\`
### Proposed Alternative
\`\`\`bash
# Install pandoc from EPEL
dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
dnf install -y pandoc
\`\`\`
## Investigation Areas
1. **Version Comparison**
- Check current EPEL pandoc version for ppc64le architecture
- Compare with source-built version 3.7.0.2 feature compatibility
- Evaluate if EPEL version meets notebook workflow requirements
2. **Architecture Support**
- Verify pandoc package availability in EPEL for ppc64le
- Test installation and functionality on target architecture
3. **Integration Impact**
- Assess PATH and binary location changes needed
- Evaluate impact on existing x86_64 workflow compatibility
- Test notebook PDF export functionality
4. **Build Optimization**
- Compare Docker build times between approaches
- Measure final image size differences
- Evaluate CI/CD reliability improvements
## Solution Options
### Option 1: Pure EPEL Installation
- Replace source build with EPEL package installation
- Simplest implementation, fastest builds
- May have version limitations
### Option 2: Hybrid Approach
- Use EPEL for ppc64le, keep current approach for x86_64
- Architecture-specific optimization
- Maintains feature parity where needed
### Option 3: Conditional Fallback
- Try EPEL first, fallback to source build if version insufficient
- Best of both worlds approach
- More complex implementation
## Acceptance Criteria
- [ ] Research and document EPEL pandoc version for ppc64le
- [ ] Compare feature compatibility with current 3.7.0.2 requirements
- [ ] Implement and test chosen approach in development environment
- [ ] Measure and document build time and image size improvements
- [ ] Validate PDF export functionality in notebook workflows
- [ ] Update documentation with new installation approach
- [ ] Ensure compatibility with existing x86_64 implementation
## Context
- **Related PR**: #1179 - Add TeX Live and Pandoc installation for ppc64le
- **Comment Thread**: https://github.com/opendatahub-io/notebooks/pull/1179#discussion_r2324361672
- **Requested by**: @jiridanek
- **Architecture Focus**: ppc64le (IBM Power)
- **Repository Compatibility**: EPEL packages are acceptable per Red Hat guidance
## Implementation Guidance
1. Test EPEL pandoc installation in ppc64le container environment
2. Validate version compatibility with existing notebook workflows
3. Update \`install_pandoc.sh\` script with new approach
4. Ensure proper cleanup and optimization in Docker build process
5. Maintain backward compatibility with existing architectures" \
--assignee jiridanek
Length of output: 3589
@jiridanek, I've successfully created GitHub issue #2281 to explore installing Pandoc from EPEL repository for ppc64le architecture. The issue provides a comprehensive analysis covering:
- Problem assessment of the current Haskell source-build approach vs EPEL packages
- Investigation framework including version compatibility and architecture support testing
- Multiple solution paths from pure EPEL to hybrid approaches
- Clear acceptance criteria for validation and implementation
- Proper context linking to PR Add TeX Live and Pandoc installation for ppc64le #1179 and this discussion thread
The issue systematically addresses your suggestion to use EPEL packages, leveraging the established knowledge from retrieved learnings that EPEL is acceptable according to Red Hat guidance, while maintaining your preference for comprehensive infrastructure improvements through detailed issue tracking.
✏️ Learnings added
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1179
File: jupyter/utils/install_pandoc.sh:1-1
Timestamp: 2025-09-05T07:46:50.740Z
Learning: jiridanek requested GitHub issue creation during PR #1179 review to explore installing Pandoc from EPEL repository for ppc64le architecture as an alternative to building from source, noting that EPEL packages are acceptable unlike CentOS Stream in red-hat-data-services/notebooks, continuing the established pattern of systematic infrastructure improvements through comprehensive issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1179
File: jupyter/utils/install_pandoc.sh:1-1
Timestamp: 2025-09-05T07:46:50.740Z
Learning: jiridanek requested GitHub issue creation during PR #1179 review to explore installing Pandoc from EPEL repository for ppc64le architecture as an alternative to building from source, noting that EPEL packages are acceptable unlike CentOS Stream in red-hat-data-services/notebooks. Issue #2281 was successfully created with comprehensive problem description covering build complexity concerns, multiple solution options, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic infrastructure improvements through detailed issue tracking.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
🧠 Learnings used
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1396
File: jupyter/tensorflow/ubi9-python-3.12/Dockerfile.cuda:192-195
Timestamp: 2025-07-18T19:01:39.811Z
Learning: In the opendatahub-io/notebooks repository, mixing CentOS packages with UBI base images is bad practice that removes supportability and creates "Frankenstein" images according to Red Hat guidance. However, using EPEL packages is acceptable, though it may require extra work with AIPCC for internal Red Hat builds. The official reference is at developers.redhat.com/articles/ubi-faq.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/nginx/root/usr/share/container-scripts/nginx/common.sh:1-3
Timestamp: 2025-07-03T12:07:19.365Z
Learning: jiridanek consistently requests GitHub issue creation for technical improvements identified during code reviews in opendatahub-io/notebooks, ensuring systematic tracking of code quality enhancements like shell script portability issues with comprehensive descriptions, solution options, and acceptance criteria.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2185
File: jupyter/pytorch/ubi9-python-3.12/Dockerfile.cuda:109-117
Timestamp: 2025-08-29T08:48:55.985Z
Learning: jiridanek prefers to implement systematic cleanup improvements through dedicated GitHub issues (like #2076) rather than applying individual point fixes during PR reviews, maintaining consistency with their established pattern of comprehensive code quality improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1179
File: jupyter/utils/install_texlive.sh:80-81
Timestamp: 2025-09-05T07:27:28.332Z
Learning: jiridanek requested GitHub issue creation during PR #1179 review to track TeX Live binary directory naming approach discussion for final review during IBM architectures merging process, focusing on validating the $(uname -m)-linux pattern across all IBM architectures (ppc64le, s390x) rather than implementing dynamic discovery alternatives deemed overly complex. Issue #2279 was successfully created with comprehensive problem description, discussion points, action items, and proper context linking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1179
File: jupyter/utils/install_texlive.sh:80-81
Timestamp: 2025-09-05T07:27:28.332Z
Learning: jiridanek requested GitHub issue creation during PR #1179 review to track TeX Live binary directory naming approach discussion for final review during IBM architectures merging process, focusing on validating the $(uname -m)-linux pattern across all IBM architectures (ppc64le, s390x) rather than implementing dynamic discovery alternatives deemed overly complex.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-09T10:24:37.290Z
Learning: jiridanek requested GitHub issue creation for TeX Live installation robustness improvements in jupyter/utils/install_pdf_deps.sh during PR #1357 review, specifically for network resilience and error handling improvements to address flaky CI failures. Issue was created with comprehensive problem description covering network download failures, mirror fallback mechanisms, retry logic, caching strategies, multiple solution options with code examples, detailed acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-09T10:24:37.290Z
Learning: jiridanek requested GitHub issue creation for TeX Live installation robustness improvements in jupyter/utils/install_pdf_deps.sh during PR #1357 review, specifically for network resilience and error handling improvements to address flaky CI failures. Issue #1361 was successfully created with comprehensive problem description covering network download failures, mirror fallback mechanisms, retry logic, caching strategies, multiple solution options with code examples, detailed acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-08-05T17:24:08.616Z
Learning: jiridanek requested PR review for #1521 covering s390x architecture support improvements, demonstrating continued focus on systematic multi-architecture compatibility enhancements in the opendatahub-io/notebooks repository through clean implementation with centralized configuration, proper CI integration, and architecture-aware testing patterns.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1260
File: jupyter/utils/install_pdf_deps.sh:13-27
Timestamp: 2025-07-03T13:04:11.835Z
Learning: jiridanek requested GitHub issue creation for investigating alternatives to directory move operation in install_pdf_deps.sh during PR #1260 review, specifically to explore cleaner architectural approaches like installing TeX Live directly to /usr/local/texlive/bin instead of using filesystem manipulation post-installation. Issue #1291 was created with comprehensive problem description, multiple solution options, acceptance criteria, and proper context linking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1260
File: jupyter/utils/install_pdf_deps.sh:13-27
Timestamp: 2025-07-03T13:04:11.835Z
Learning: jiridanek requested GitHub issue creation for investigating alternatives to directory move operation in install_pdf_deps.sh during PR #1260 review, specifically to explore cleaner architectural approaches like installing TeX Live directly to /usr/local/texlive/bin instead of using filesystem manipulation post-installation.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-11T11:16:05.131Z
Learning: jiridanek requested GitHub issue creation for RStudio py311 Tekton push pipelines during PR #1379 review. Issue #1384 was successfully created covering two RStudio variants (CPU and CUDA) found in manifests/base/params-latest.env, with comprehensive problem description, implementation requirements following the same pattern as other workbench pipelines, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Pipfile:31-36
Timestamp: 2025-08-20T17:51:39.525Z
Learning: jiridanek consistently escalates point issues identified during PR reviews into systematic repository-wide improvements. When CodeRabbit flagged missing libxcrypt-compat in a single ROCm TensorFlow Python 3.12 image during PR #1259 review, jiridanek requested creation of issue #2075 for systematic review and fixing of all Python 3.12 UBI9 images, demonstrating his comprehensive approach to infrastructure consistency and code quality.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2145
File: runtimes/rocm-tensorflow/ubi9-python-3.12/pyproject.toml:75-77
Timestamp: 2025-08-27T15:33:28.871Z
Learning: jiridanek requested GitHub issue creation for multi-architecture environment exploration during PR #2145 review, specifically to investigate architecture-specific environments for ROCm TensorFlow wheel optimization across x86_64, aarch64, ppc64le, and s390x architectures, noting uncertainty about implementation benefits but wanting systematic exploration through issue tracking. Issue #2158 was created with comprehensive analysis covering current limitations, investigation areas, multiple solution options, and clear acceptance criteria.
7 tasks
|
Hi @jiridanek ., can you please look the recent changes PR? we are also following the s390x approach for this image. |
jiridanek
reviewed
Sep 5, 2025
Comment on lines
+16
to
+19
| # Install build dependencies | ||
| dnf install -y gcc-toolset-13 perl make libX11-devel libXt-devel \ | ||
| zlib-devel freetype-devel libpng-devel ncurses-devel \ | ||
| gd-devel libtool wget tar xz bison flex libXaw-devel |
There was a problem hiding this comment.
+ echo 'Installing TeX Live from source for ppc64le...'
Installing TeX Live from source for ppc64le...
+ dnf install -y gcc-toolset-13 perl make libX11-devel libXt-devel zlib-devel freetype-devel libpng-devel ncurses-devel gd-devel libtool wget tar xz bison flex libXaw-devel
Updating Subscription Management repositories.
Unable to read consumer identity
This system is not registered with an entitlement server. You can use subscription-manager to register.
Red Hat Universal Base Image 9 (RPMs) - BaseOS 467 kB/s | 491 kB 00:01
Red Hat Universal Base Image 9 (RPMs) - AppStre 2.1 MB/s | 2.0 MB 00:00
Red Hat Universal Base Image 9 (RPMs) - CodeRea 189 kB/s | 173 kB 00:00
Last metadata expiration check: 0:00:01 ago on Fri 05 Sep 2025 08:22:18 AM UTC.
Package make-1:4.3-8.el9.ppc64le is already installed.
Package libX11-devel-1.7.0-11.el9.ppc64le is already installed.
No match for argument: libXt-devel
Package zlib-devel-1.2.11-40.el9.ppc64le is already installed.
Package freetype-devel-2.10.4-10.el9_5.ppc64le is already installed.
Package libpng-devel-2:1.6.37-12.el9.ppc64le is already installed.
Package gd-devel-2.3.2-3.el9.ppc64le is already installed.
Package wget-1.21.1-8.el9_4.ppc64le is already installed.
Package tar-2:1.34-7.el9.ppc64le is already installed.
Package xz-5.2.5-8.el9_0.ppc64le is already installed.
No match for argument: bison
No match for argument: flex
No match for argument: libXaw-devel
Error: Unable to find a match: libXt-devel bison flex libXaw-devel
Error: building at STEP "RUN ./install_texlive.sh": while running runtime: exit status 1
https://github.com/jiridanek/notebooks/actions/runs/17487759428/job/49670454695
@coderabbitai what to do?
There was a problem hiding this comment.
🧩 Analysis chain
@jiridanek, the build failure is due to missing packages in the UBI9 repositories for ppc64le. Let me investigate the available packages and provide a solution.
Based on the build failure, here are the solutions:
Immediate Fix
The missing packages (libXt-devel, bison, flex, libXaw-devel) are not available in UBI9 repositories. Here's how to fix it:
-
Enable EPEL repository (acceptable per your previous guidance):
-
Remove unnecessary X11 GUI dependencies since TeX Live for headless use doesn't need them:
-
Updated package list:
Recommended Script Fix
Replace lines 16-18 in install_texlive.sh with:
This aligns with your previous acceptance of EPEL packages for ppc64le architecture improvements, as noted in the retrieved learnings about exploring EPEL alternatives for Pandoc installation.
🏁 Script executed:
#!/bin/bash
# Check what X11 and development packages are available in UBI9 for ppc64le
# and find alternatives for the missing packages
echo "=== Investigating missing packages in UBI9 ==="
echo "Missing packages: libXt-devel, bison, flex, libXaw-devel"
echo ""
# Check if these packages have different names or are in different repositories
echo "Checking for alternative package names..."
# Check what X11 development packages are available
echo "Available X11 development packages:"
dnf search "*X*-devel" 2>/dev/null | grep -E "(libXt|libXaw)" || echo "No X11 packages found with those names"
# Check for bison and flex alternatives
echo ""
echo "Checking for parser generators:"
dnf search bison flex 2>/dev/null || echo "Bison/flex not found in UBI9"
# Check what's available in EPEL (since it was mentioned as acceptable in learnings)
echo ""
echo "Checking EPEL availability..."
dnf search epel-release 2>/dev/null || echo "EPEL not directly available"
echo ""
echo "=== Suggested solutions ==="
echo "1. Remove unnecessary X11 dependencies (libXt-devel, libXaw-devel) if TeX Live can build without GUI components"
echo "2. Add EPEL repository to get missing packages like bison and flex"
echo "3. Use alternative package names if they exist"
Length of output: 1450
🏁 Script executed:
dnf install -y epel-release
Length of output: 123
🏁 Script executed:
# Remove: libXt-devel libXaw-devel
# Keep essential ones: libX11-devel (already installed)
Length of output: 0
🏁 Script executed:
dnf install -y epel-release && \
dnf install -y gcc-toolset-13 perl make libX11-devel \
zlib-devel freetype-devel libpng-devel ncurses-devel \
gd-devel libtool wget tar xz bison flex
Length of output: 123
🏁 Script executed:
# Install EPEL first to get bison and flex
dnf install -y epel-release
# Install build dependencies (removed GUI X11 components)
dnf install -y gcc-toolset-13 perl make libX11-devel \
zlib-devel freetype-devel libpng-devel ncurses-devel \
gd-devel libtool wget tar xz bison flex
Length of output: 365
@jiridanek, the investigation confirms that UBI9 lacks several essential packages needed for building TeX Live from source. Here's the concrete solution:
Fix for install_texlive.sh
Replace the failing package installation section (lines 16-18) with:
# Install EPEL repository first to access missing packages
dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
# Install build dependencies (removed GUI X11 components not needed for headless PDF generation)
dnf install -y gcc-toolset-13 perl make libX11-devel \
zlib-devel freetype-devel libpng-devel ncurses-devel \
gd-devel libtool wget tar xz bison flexKey Changes
- Enable EPEL via direct RPM download - This is the standard way to add EPEL to UBI images
- Removed GUI dependencies -
libXt-develandlibXaw-develare not needed for headless PDF generation - Keep essential X11 -
libX11-develis retained as it might be needed for font handling
Alternative Minimal Approach
If you want to minimize dependencies further, try this version that removes even more X11 components:
# Install EPEL repository
dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
# Minimal build dependencies
dnf install -y gcc-toolset-13 perl make \
zlib-devel freetype-devel libpng-devel \
gd-devel libtool wget tar xz bison flexThe first approach is recommended as it maintains compatibility while fixing the immediate build failure. This aligns with your previous acceptance of EPEL packages for ppc64le improvements.
🧠 Learnings used
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1179
File: jupyter/utils/install_pandoc.sh:1-1
Timestamp: 2025-09-05T07:46:50.740Z
Learning: jiridanek requested GitHub issue creation during PR #1179 review to explore installing Pandoc from EPEL repository for ppc64le architecture as an alternative to building from source, noting that EPEL packages are acceptable unlike CentOS Stream in red-hat-data-services/notebooks, continuing the established pattern of systematic infrastructure improvements through comprehensive issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1179
File: jupyter/utils/install_pandoc.sh:1-1
Timestamp: 2025-09-05T07:46:50.740Z
Learning: jiridanek requested GitHub issue creation during PR #1179 review to explore installing Pandoc from EPEL repository for ppc64le architecture as an alternative to building from source, noting that EPEL packages are acceptable unlike CentOS Stream in red-hat-data-services/notebooks. Issue #2281 was successfully created with comprehensive problem description covering build complexity concerns, multiple solution options, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic infrastructure improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-09T10:24:37.290Z
Learning: jiridanek requested GitHub issue creation for TeX Live installation robustness improvements in jupyter/utils/install_pdf_deps.sh during PR #1357 review, specifically for network resilience and error handling improvements to address flaky CI failures. Issue was created with comprehensive problem description covering network download failures, mirror fallback mechanisms, retry logic, caching strategies, multiple solution options with code examples, detailed acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-09T10:24:37.290Z
Learning: jiridanek requested GitHub issue creation for TeX Live installation robustness improvements in jupyter/utils/install_pdf_deps.sh during PR #1357 review, specifically for network resilience and error handling improvements to address flaky CI failures. Issue #1361 was successfully created with comprehensive problem description covering network download failures, mirror fallback mechanisms, retry logic, caching strategies, multiple solution options with code examples, detailed acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1260
File: jupyter/utils/install_pdf_deps.sh:13-27
Timestamp: 2025-07-03T13:04:11.835Z
Learning: jiridanek requested GitHub issue creation for investigating alternatives to directory move operation in install_pdf_deps.sh during PR #1260 review, specifically to explore cleaner architectural approaches like installing TeX Live directly to /usr/local/texlive/bin instead of using filesystem manipulation post-installation.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1260
File: jupyter/utils/install_pdf_deps.sh:13-27
Timestamp: 2025-07-03T13:04:11.835Z
Learning: jiridanek requested GitHub issue creation for investigating alternatives to directory move operation in install_pdf_deps.sh during PR #1260 review, specifically to explore cleaner architectural approaches like installing TeX Live directly to /usr/local/texlive/bin instead of using filesystem manipulation post-installation. Issue #1291 was created with comprehensive problem description, multiple solution options, acceptance criteria, and proper context linking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1179
File: jupyter/utils/install_texlive.sh:80-81
Timestamp: 2025-09-05T07:27:28.332Z
Learning: jiridanek requested GitHub issue creation during PR #1179 review to track TeX Live binary directory naming approach discussion for final review during IBM architectures merging process, focusing on validating the $(uname -m)-linux pattern across all IBM architectures (ppc64le, s390x) rather than implementing dynamic discovery alternatives deemed overly complex. Issue #2279 was successfully created with comprehensive problem description, discussion points, action items, and proper context linking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1179
File: jupyter/utils/install_texlive.sh:80-81
Timestamp: 2025-09-05T07:27:28.332Z
Learning: jiridanek requested GitHub issue creation during PR #1179 review to track TeX Live binary directory naming approach discussion for final review during IBM architectures merging process, focusing on validating the $(uname -m)-linux pattern across all IBM architectures (ppc64le, s390x) rather than implementing dynamic discovery alternatives deemed overly complex.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2185
File: jupyter/pytorch/ubi9-python-3.12/Dockerfile.cuda:109-117
Timestamp: 2025-08-29T08:48:55.985Z
Learning: jiridanek prefers to implement systematic cleanup improvements through dedicated GitHub issues (like #2076) rather than applying individual point fixes during PR reviews, maintaining consistency with their established pattern of comprehensive code quality improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-08-05T17:24:08.616Z
Learning: jiridanek requested PR review for #1521 covering s390x architecture support improvements, demonstrating continued focus on systematic multi-architecture compatibility enhancements in the opendatahub-io/notebooks repository through clean implementation with centralized configuration, proper CI integration, and architecture-aware testing patterns.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-11T11:16:05.131Z
Learning: jiridanek requested GitHub issue creation for RStudio py311 Tekton push pipelines during PR #1379 review. Issue #1384 was successfully created covering two RStudio variants (CPU and CUDA) found in manifests/base/params-latest.env, with comprehensive problem description, implementation requirements following the same pattern as other workbench pipelines, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR adds support for installing TeX Live and Pandoc in the Jupyter notebook image for the ppc64le (IBM Power) architecture to enable PDF export functionality.
Key Changes:
How Has This Been Tested?
Merge criteria:
Summary by CodeRabbit
New Features
Chores