fedora-docs / package-maintainer-docs

#182 New_Package_Process_for_New_Contributors needs updates for rpmautospec
Closed by oturpe. Opened by decathorpe.

Closed
Reopen Issue

https://docs.fedoraproject.org/en-US/package-maintainers/New_Package_Process_for_New_Contributors/#import_commit_and_build_your_package

This section only mentions fedpkg import to import your package. However, with rpmautospec being the default for packages now, fedpkg import doesn't work.

This should probably be updated to mention using fedpkg new-sources for large / binary data (like tarballs) and git add for text files (either instead, or in addition to fedpkg import).

fedpkg import still works fine for me with spec files using rpmautospec. When I submit new packages, I'll build them in copr, and use the copr links for the spec file and SRPM for the review. The spec file in that SRPM preserves %autorelease and %autochangelog. Here's a recent example. Are you seeing some kind of failure due to a SRPM that doesn't preserve those macros?

Interesting.

The recommendation for building an SRPM locally is fedpkg srpm, which produces SRPM files that are processed by rpmautospec, so they can't be cleanly imported by fedpkg import AFAICT.

rpkg handles this by reverting rpmautospec processing internally, see https://pagure.io/rpkg/pull-request/699. To confirm this, I tested it, using the banner package:

  1. Generate SRPM with fedpkg srpm
  2. Initialize a new Git repo banner-2, copy banner.spec there, make some changes
  3. In the new repo, run fedpkg import ../banner/path/to/banner.src.rpm
  4. Checked that banner-2/banner.spec was updated to match the original

It worked just fine.

Closing this now as everything seems to work. Please reopen with more details if needed.
Edited by oturpe

Metadata Update from @oturpe:
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
None
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.