Add TeX Live and Pandoc installation for ppc64le #1179

jiridanek · 2025-09-05T07:45:52Z

@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

🧩 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.

jiridanek · 2025-09-05T08:23:21Z

+ 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?

🧩 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 flex

Key Changes

Enable EPEL via direct RPM download - This is the standard way to add EPEL to UBI images

Removed GUI dependencies - libXt-devel and libXaw-devel are not needed for headless PDF generation

Keep essential X11 - libX11-devel is 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 flex

The 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.

coderabbitai · 2025-07-14T09:57:31Z

🛠️ 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.

isn't this overly complicated?

@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.

@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

🧩 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)-linux vs 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.

-Original file line number
+Diff line change
@@ -1,3 +1,21 @@
+    ############################
+    # Stage 1: PDF Tool Build #
+    ############################
+    FROM registry.access.redhat.com/ubi9/python-311:latest AS pdf-builder
+    WORKDIR /opt/app-root/bin
+    # OS Packages needs to be installed as root
+    USER 0
+    # Copy scripts
+    COPY jupyter/utils/install_texlive.sh ./install_texlive.sh
+    COPY jupyter/utils/install_pandoc.sh ./install_pandoc.sh
+    RUN chmod +x install_texlive.sh install_pandoc.sh
+    RUN ./install_texlive.sh
+    RUN ./install_pandoc.sh
     ####################
     # base             #
     ####################
@@ Expand Down Expand Up / @@ -47,8 +65,10 @@ COPY ${JUPYTER_REUSABLE_UTILS} utils/ @@
     USER 0
-    # Dependencies for PDF export
-    RUN ./utils/install_pdf_deps.sh
+    # Copy built TeXLive and Pandoc binaries only (no build deps)
+    COPY --from=pdf-builder /usr/local/texlive /usr/local/texlive
+    COPY --from=pdf-builder /usr/local/pandoc /usr/local/pandoc
     ENV PATH="/usr/local/texlive/bin/linux:/usr/local/pandoc/bin:$PATH"
     USER 1001
@@ Expand All / @@ -74,3 +94,4 @@ RUN echo "Installing softwares and packages" && \ @@
     WORKDIR /opt/app-root/src
     ENTRYPOINT ["start-notebook.sh"]

-Original file line number
+Diff line change
@@ -1,3 +1,21 @@
+    ############################
+    # Stage 1: PDF Tool Build #
+    ############################
+    FROM registry.access.redhat.com/ubi9/python-312:latest AS pdf-builder
+    WORKDIR /opt/app-root/bin
+    # OS Packages needs to be installed as root
+    USER 0
+    # Copy scripts
+    COPY jupyter/utils/install_texlive.sh ./install_texlive.sh
+    COPY jupyter/utils/install_pandoc.sh ./install_pandoc.sh
+    RUN chmod +x install_texlive.sh install_pandoc.sh
+    RUN ./install_texlive.sh
+    RUN ./install_pandoc.sh
     ####################
     # base             #
     ####################
@@ Expand Down Expand Up / @@ -47,8 +65,10 @@ COPY ${JUPYTER_REUSABLE_UTILS} utils/ @@
     USER 0
-    # Dependencies for PDF export
-    RUN ./utils/install_pdf_deps.sh
+    # Copy built TeXLive and Pandoc binaries only (no build deps)
+    COPY --from=pdf-builder /usr/local/texlive /usr/local/texlive
+    COPY --from=pdf-builder /usr/local/pandoc /usr/local/pandoc
     ENV PATH="/usr/local/texlive/bin/linux:/usr/local/pandoc/bin:$PATH"
     USER 1001
@@ Expand Down @@

-Original file line number
+Diff line change
@@ -0,0 +1,53 @@
+    #!/bin/bash
+    set -euxo pipefail
+    # Mapping of `uname -m` values to equivalent GOARCH values
+    declare -A UNAME_TO_GOARCH
+    UNAME_TO_GOARCH["x86_64"]="amd64"
+    UNAME_TO_GOARCH["aarch64"]="arm64"
+    UNAME_TO_GOARCH["ppc64le"]="ppc64le"
+    UNAME_TO_GOARCH["s390x"]="s390x"
+    ARCH="${UNAME_TO_GOARCH[$(uname -m)]}"
+    if [[ "$ARCH" == "ppc64le" ]]; then
+      # Install Pandoc from source
+      dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
+      dnf install -y cabal-install ghc gmp-devel
+      # Set version
+      PANDOC_VERSION=3.7.0.2
+      cd /tmp
+      git clone --recurse-submodules https://github.com/jgm/pandoc.git
+      cd pandoc
+      git checkout ${PANDOC_VERSION}
+      git submodule update --init --recursive
+      cabal update
+      cd pandoc-cli
+      cabal build -j"$(nproc)"
+      mkdir -p /usr/local/pandoc/bin
+      cabal install \
+        --installdir=/usr/local/pandoc/bin \
+        --overwrite-policy=always \
+        --install-method=copy
+      # Clean up Haskell build system
+      rm -rf ~/.cabal ~/.ghc /tmp/pandoc
+      dnf remove -y cabal-install ghc gmp-devel
+      dnf clean all && rm -rf /var/cache/dnf
+      /usr/local/pandoc/bin/pandoc --version
+    elif [[ "$ARCH" == "amd64" ]]; then
+      # pandoc installation
+      curl -fL "https://github.com/jgm/pandoc/releases/download/3.7.0.2/pandoc-3.7.0.2-linux-${ARCH}.tar.gz"  -o /tmp/pandoc.tar.gz
+      mkdir -p /usr/local/pandoc
+      tar xvzf /tmp/pandoc.tar.gz --strip-components 1 -C /usr/local/pandoc/
+      rm -f /tmp/pandoc.tar.gz
+    else
+      echo "Unsupported architecture: $ARCH" >&2
+      exit 1
+    fi

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Add TeX Live and Pandoc installation for ppc64le #1179

Uh oh!

Diff view

Diff view

There are no files selected for viewing

jiridanek Sep 5, 2025

Uh oh!

coderabbitai bot Sep 5, 2025

Uh oh!

Uh oh!

jiridanek Sep 5, 2025

Uh oh!

coderabbitai bot Sep 5, 2025

Uh oh!

coderabbitai bot Jul 14, 2025 •

edited

Loading

Uh oh!

jiridanek Jul 25, 2025

Uh oh!

coderabbitai bot Jul 25, 2025

Uh oh!

jiridanek Sep 5, 2025

Uh oh!

coderabbitai bot Sep 5, 2025

Uh oh!

Uh oh!

Add TeX Live and Pandoc installation for ppc64le #1179

Are you sure you want to change the base?

Uh oh!

Add TeX Live and Pandoc installation for ppc64le #1179

Uh oh!

Uh oh!

Diff view

Diff view

There are no files selected for viewing

jiridanek Sep 5, 2025

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot Sep 5, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jiridanek Sep 5, 2025

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot Sep 5, 2025

Choose a reason for hiding this comment

Immediate Fix

Recommended Script Fix

Fix for install_texlive.sh

Key Changes

Alternative Minimal Approach

Uh oh!

coderabbitai bot Jul 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jiridanek Jul 25, 2025

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot Jul 25, 2025

Choose a reason for hiding this comment

Uh oh!

jiridanek Sep 5, 2025

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot Sep 5, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

coderabbitai bot Jul 14, 2025 •

edited

Loading