Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

superplayer-moq ships one ABI from a locally built artifact: what publishing it would need

Open
  • Is something wrong?
#369 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
8/100
Issue type
Documentation
Clarity
Needs clarification
Activity status
Active
Tech stack
android, kotlin
Domain
build-system, mobile

Research direction

This is a tracking note, not a task: it records why the Phase 14 MoQ module stays out of the published set. Relevant files are settings.gradle.kts (the published set), docs/compatibility.md (the stability table, checked by verifyCompatibilityDocument), THIRD_PARTY.md and CONTRIBUTING.md (the dependency policy). Done means a maintainer decision on the licence and build-matrix conditions, not a code change.

Written by the indexing model from the issue text.

Description

question

What this is

A tracked limit, not a ticket to pick up. Phase 14's MoQ module links a locally built
moq-ffi for arm64-v8a only, and is deliberately excluded from the published set (#351,
#364). This issue is where what shipping would actually need is written down, so that "unpublished"
stays a decision rather than becoming an oversight.

What is missing

  • armeabi-v7a and x86_64 are unbuilt and untested. #351 built arm64 alone because this host
    is Apple Silicon and its only system image is arm64. Upstream ships all three.
  • No Intel-host emulator can run this, which narrows who can reproduce a Phase 14 result.
  • The artifact is not reproducible by a consumer. It is built from a source checkout with
    --no-default-features, which is what subtracts the MPL-2.0 decoder crates from the graph
    (#351). The Maven artifact a consumer would resolve does not carry that subtraction, so
    publishing this module against the upstream coordinate would reintroduce exactly the licence
    problem #351 closed.

That last point is the real content here. The ABI gap is a build-matrix problem; the licence gap is
a policy problem, and it is the one that decides whether this module can ever publish.

What would have to be true to publish

  • A reproducible build of moq-ffi with default features off, for every ABI the library targets,
    produced by something other than one developer's machine.
  • Either an upstream change that makes the decoder feature opt-in rather than default, or a
    published artifact of our own with its provenance stated — at which point THIRD_PARTY.md and
    CONTRIBUTING.md's dependency policy are both back in scope.
  • docs/compatibility.md's stability table and settings.gradle.kts' published set agree on the
    module's presence, which verifyCompatibilityDocument checks as a set.

Proposing the feature change upstream is adjacent to #354 and carries no work in this repository.

Blocked by

Nothing. This blocks nothing in Phase 14 either; the phase's exit criterion is a broadcast playing
on a device, and an unpublished module satisfies it.

Dominant language
Kotlin
Stars
1
Forks
0
Avg merge
1h 12m
Merged PRs (30d)
195

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ramesh130/superplayer

All issues in ramesh130/superplayer

Similar issues

More Kotlin issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.