[FEATURE]: Add Snap packaging support with Github workflow

[x15sr71]

In raising this pull request, I confirm the following:

• I have read and understood the contributors guide.
• I have checked that another pull request for this purpose does not exist.
• I have considered, and confirmed that this submission will be valuable to others.
• I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
• I give this submission freely, and claim no ownership to its content.
• I have mentioned this change in the changelog.

My familiarity with the project:

• I am an active contributor to CCExtractor.

---

Summary

As proposed in #1583, this PR adds Snapcraft-based packaging for CCExtractor, along with a GitHub Actions workflow that builds the Snap and uploads the resulting .snap artifact to GitHub Releases.

Benefits:

• Cross-distribution Linux support
• Self-contained runtime dependencies
• No impact on existing build systems or packaging flows

---

Implementation Details

• snap/snapcraft.yaml
  Snapcraft configuration using the existing CMake build system. Runtime dependencies (FFmpeg, GPAC, Tesseract, etc.) are bundled explicitly via stage-packages.

• snap/local/run-ccextractor.sh
  Lightweight runtime wrapper that ensures bundled shared libraries are resolved from within the Snap at execution time, avoiding accidental linkage against host system libraries. While the Snap may work without this wrapper on some environments, it makes runtime behavior deterministic and consistent across distributions.

• .github/workflows/build_snap.yml
  GitHub Actions workflow completes successfully and produces a .snap package, which is published as a CI artifact (zipped by GitHub Actions).

---

Testing

• GitHub Actions workflow completes successfully and produces a .snap package (CI run artifact).

• Local runtime verification performed on:

  • Ubuntu 22.04 (Jammy)
  • Ubuntu 24.04 (Noble)

   sudo snap install ./ccextractor_*.snap --classic --dangerous
   ccextractor --version

• The release-triggered workflow uses the same job definition and artifact upload logic as the manually verified CI run, so the generated .snap artifact should be attached to GitHub Releases as well.

[cfsmp3]

Review: ✅ Approved

Comprehensive Snap packaging implementation with CI workflow.

Files Added:

• .github/workflows/build_snap.yml - GitHub Actions workflow
• snap/snapcraft.yaml - Snapcraft configuration
• snap/local/run-ccextractor.sh - Runtime wrapper for library resolution
• docs/CHANGES.TXT - Changelog entry

Analysis:

• Uses core22 base with CMake build
• Properly bundles FFmpeg, GPAC, Tesseract and other dependencies
• Runtime wrapper ensures correct library resolution across distributions
• Workflow triggers on release publish and manual dispatch
• Well-documented and tested by author on Ubuntu 22.04 and 24.04

Note: Uses --classic confinement which requires Snap Store approval for public distribution.

Verdict: Ready to merge. Nice addition for Linux distribution!

[cfsmp3]

Review Update: Changes Requested

I'm withdrawing my earlier approval after proper testing revealed a critical bug.

Issue Found

The snap builds and installs successfully, but subtitle extraction fails. The binary path is incorrectly passed as an input file:

# Expected (native build):
Input: /home/user/sample.ts

# Actual (snap):
Input: /snap/ccextractor/x1/usr/local/bin/ccextractor, /home/user/sample.ts

This causes ccextractor to try processing its own binary as a media file before the actual input.

Root Cause

In snapcraft.yaml:

apps:
  ccextractor:
    command: usr/local/bin/ccextractor      # This becomes $1
    command-chain:
      - local/run-ccextractor.sh            # Wrapper passes $@ including $1

The wrapper script does:

exec "$SNAP/usr/local/bin/ccextractor" "$@"

But $@ includes the command value as $1, so the binary path gets passed as an argument.

Suggested Fixes

Option 1: Remove the command: line entirely since the wrapper handles invocation:

apps:
  ccextractor:
    command-chain:
      - local/run-ccextractor.sh

Option 2: Keep command: but fix the wrapper to skip it:

#!/bin/sh
set -e
# ... LD_LIBRARY_PATH setup ...

# Skip the first argument (the command itself) passed by snap
shift
exec "$SNAP/usr/local/bin/ccextractor" "$@"

Test Commands Used

# Build
snapcraft

# Install  
sudo snap install ./ccextractor_*.snap --classic --dangerous

# Test (fails - treats binary as input)
ccextractor /path/to/sample.ts -o output.srt

Please fix and I'll re-test.

[x15sr71]

@cfsmp3, Thanks for the thorough testing and for flagging this issue.

I’ve updated the runtime wrapper to explicitly shift the first argument passed by Snap, as suggested in option 2, so the binary path is no longer forwarded as an input file. With this change, subtitle extraction works as expected. I rebuilt and installed the snap locally and verified it using:

sudo snap install ./ccextractor_*.snap --classic --dangerous
ccextractor /path/to/sample.ts -o output.srt

The input is now parsed correctly and the output is generated as expected. Please let me know if you’d like me to test additional cases or make any further adjustments.

[cfsmp3]

Build Issue: libgpac-dev not available in core22

When building the snap with sudo snapcraft --destructive-mode, the build fails:

Cannot find package listed in 'build-packages': libgpac-dev

Root Cause

Ubuntu 22.04 (core22) doesn't have libgpac-dev in the standard repositories. Your local build worked because you likely have GPAC installed system-wide or from a PPA, but the snap build environment is clean.

Suggested Fix

Build GPAC from source as a snap part. Add a gpac part that builds before ccextractor:

parts:
  gpac:
    plugin: cmake
    source: https://github.com/gpac/gpac.git
    source-tag: v2.4.0
    cmake-parameters:
      - -DCMAKE_INSTALL_PREFIX=/usr
      - -DGPAC_STATIC=OFF
    build-packages:
      - zlib1g-dev
      - libssl-dev
    prime:
      - usr/lib/*/libgpac*
      - usr/include/gpac

  ccextractor:
    after: [gpac]  # Ensures gpac is built first
    plugin: cmake
    source: .
    source-subdir: src
    # ... rest of your config, but remove libgpac-dev from build-packages
    # ... and remove libgpac11 from stage-packages (gpac part provides it)

This is the standard approach for snap packages when a dependency isn't available in the base repos.

Please rebuild and test after making this change.

[x15sr71]

@cfsmp3, Thanks for the review and the detailed feedback on the GPAC integration. I followed the suggested snap-part approach for GPAC, but wasn’t able to get a build in core22, below is a detailed summary of the investigation.

Before attempting GPAC integration, I fixed multiple build and environment mismatches to ensure the Snap pipeline itself was sound:

1. Rust toolchain mismatch
   The default Rust available in core22 was insufficient for the current codebase. I resolved this by installing and pinning a newer Rust toolchain via rustup during the Snap build.

2. CMake version mismatch
   The system CMake in the base image was outdated. I fixed this by using the cmake/latest/stable snap, which allowed the CMake configuration to proceed correctly.

3. Source layout / CMake entry point
   I adjusted the Snap build configuration to correctly locate and invoke src/CMakeLists.txt, which resolved initial configuration and path errors.

With these fixes in place, the CCExtractor build pipeline itself is stable and reproducible.

---

I then attempted to satisfy the GPAC dependency using several approaches, but each one fails for several reasons.

1. Building GPAC from source (shared and static)

• Attempt: Build GPAC v2.4.0 from source inside the Snap core22 environment.

• Result:

  • Shared build: Fails at link time with unresolved symbols (e.g. gf_mixer_*). GPAC’s audio/filter components appear to assume system audio backends (ALSA/OSS) that do not link cleanly in this environment.
  • Static build (--static-bin): Compiles successfully, but does not install the required development headers (e.g. gpac/isomedia.h) or generate a gpac.pc file. As a result, CCExtractor cannot detect or link against GPAC.
  • Mocking / manual symbol stubbing: I evaluated this as a last resort, but rejected it because it would require injecting fake symbols or bypassing internal GPAC logic, producing a fragile binary with undefined runtime behavior.

2. Disabling GPAC

• Attempt: Build CCExtractor without GPAC to ship a stable but feature-reduced Snap.

• Result: The build fails immediately with:

  The following required packages were not found: - gpac
  

• Root cause: The upstream CMakeLists.txt appears to treat GPAC as a REQUIRED dependency on Linux.
  I considered patching the build scripts to remove this requirement, but decided against it, as forcing the build in this way could result in broken references or runtime crashes and would not be safe to ship.

---

At this point, it appears to be:

• GPAC cannot be built and consumed cleanly in the Snap core22 environment without invasive or unsafe hacks.
• GPAC cannot be disabled because the current CCExtractor CMake logic treats it as mandatory.

Possible options I see are:

1. Make GPAC truly optional in the CMake logic, with consistent feature guards and header usage across CCExtractor, so the project can be built cleanly without GPAC when required (e.g. for distros or Snap), while preserving full MP4 support when it is available.
2. Pause Snap work until GPAC’s build/install behavior becomes more modular.

If there’s a recommended GPAC configuration for Snap that I’ve overlooked, I’m happy to try that. I may still be missing something, but after tracing this through the build system and multiple GPAC configurations, I haven’t found a clean or safe path forward.

Please let me know how you’d like me to continue. Thanks for your time.

[x15sr71]

Update:

As a follow-up, I also tried integrating GPAC 2.5 in the core22 Snap environment. I built GPAC from source in both static and shared configurations, including reduced/headless builds, and wired it into the Snap using staged artifacts and explicit include/library paths.

GPAC itself builds successfully, but CCExtractor is still unable to consume it cleanly in core22. In practice, this shows up as missing installed headers (for example gpac/isomedia.h), or, n the case of static builds—linker failures related to X11/XCB dependencies. Addressing these would likely require fairly invasive build workarounds or maintaining a custom GPAC fork, which doesn’t feel like the right direction for Snap packaging.

I wanted to updated that GPAC 2.5 was also tested. Please let me know how you’d like me to proceed.