fedora-infrastructure

#10330 MBS still uses "master" for default branch name
Closed: Fixed by mohanboddu. Opened by orion.

Closed: Fixed
Reopen Issue

Describe what you would like us to do:

I submitted a module build for octave 6.4 which uses default (unspecified) branch names:

  components:
    rpms:
      octave:
        rationale: The core package
        buildorder: 10
        ref: 6.4
      octave-control:
        rationale: Extra package
        buildorder: 20
      octave-dicom:
        rationale: Extra package
        buildorder: 20
....

This failed with:

Failed to get the latest commit for git+https://src.fedoraproject.org/rpms/octave-communications#master\nFailed to get the latest commit for git+https://src.fedoraproject.org/rpms/octave-control#master\nFailed to get the latest commit for git+https://src.fedoraproject.org/rpms/octave-dicom#master...

https://mbs.fedoraproject.org/module-build-service/2/module-builds/13373

When do you need this to be done by? (YYYY/MM/DD)

Not critical, I can specify "rawhide" manually.

This was I think intended from https://pagure.io/fesco/issue/2573

ie, modules were intentially left with master where they had it, but improvements were going to be made to make it possible to not have it moving forward.

@mohanboddu thoughts? Should we track that work in releng tracker? or fedscmadmin? or are we already?

I'm noting that we're trying to pull the "master" branch from the rpms by default, not whether or not the module repo has a master branch. But perhaps it's related.

Filed it upstream, closing this ticket.

Metadata Update from @mohanboddu:
- Issue close_status updated to: Upstream
- Issue status updated to: Closed (was: Open)

This appears to be the upstream issue — https://pagure.io/fm-orchestrator/issue/1735

Commit ad7f0422 fixes this issue
Metadata
None
None
None
None
Lowest
Related Pull Requests
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.