I've used fedpkg import for new packages using %autorelease/%autochangelog and it worked fine. fedpkg new-sources is for uploading source tarballs to the lookaside cache, and doesn't import the spec file and patches like you'll need to at this part of the tutorial. When did you run into this error?

I've used fedpkg import for new packages using %autorelease/%autochangelog and it worked fine. fedpkg new-sources is for uploading source tarballs to the lookaside cache, and doesn't import the spec file and patches like you'll need to at this part of the tutorial. When did you run into this error?

Did some more digging and found this, which is what I ran into.

https://pagure.io/rpkg/pull-request/628

Ah I see. Still, fedpkg import is not the answer. The docs should guide users to fix the SRPM they are importing instead.

When I'm submitting new packages, I do a local mock build, upload the resulting SRPM for a COPR build, then use the COPR links for the spec file and SRPM links in the review. I checked my most recent review, and both the local SRPM (built with mock) and the COPR SRPM have unexpanded %autorelease/%autochangelog macros. How did you create your SRPM that triggered that error? I think the best approach would be to rework the note to let users know if they see that warning to rebuild their SRPM using mock.

Yeah, i guess I am confused about this even more now. The SRPM i tried to use was built with mock, and trying around a few more times, it appears I made it with fedpkg mockbuild. Building it with 'normal' mock against f37 results in a non-processed spec inside the srpm.

I'm not sure what the disconnect is between how fedpkg invokes mock vs how I would (just mock -r someconfig --sources ... --spec some.spec e.g.).

Agreed that this note in its current form is incorrect.. I will make a fix tomorrow

If you use fedpkg, the srpm is generated with fedpkg srpm,
which does rpmautospec expansion.
Other methods do not.

If one is using rpmautospec in a git repo for the review, one can "rebase" it onto the new repo once its been created in src.fp.o---this does not need one to use fedpkg import at all. I've got the steps written here, but not yet sure where in the docs they should go:

56

facepalm.jpg

Thank you all. I understand now.

@ankursinha I'll try and take a shot at #56 if you'd like, as part of this. Probably makes sense to make a new page and link to it from the relevant pages, what do you think?

If you use fedpkg, the srpm is generated with fedpkg srpm,

This is strange to me. I did verify that it is the case, building a srpm with fedpkg --release f38 srpm in a regular directory (not a git checkout) with a tarball and spec file. The macros are expanded in the spec file inside the resulting srpm. The --help output for this command says it's roughly equivalent to rpmbuild -bs, however if I directly create a srpm with that command the macros are not expanded in the spec file inside the resulting srpm. fedpkg is doing something different that results in these being expanded and resulting in a srpm that is incompatible with fedpkg import. Personally I would be fine with just guiding people to create their review srpm with mock or rpmbuild directly, but I understand that many would like to encourage the use of fedpkg even at this early stage.

Another observation, creating a srpm with fedpkg --release f38 srpm --srpm-mock creates a valid srpm (unexpanded macros in spec file inside) for fedpkg import. It takes longer but perhaps that should be the recommendation.

For all the good things rpmautospec brings,
the specfile conversion creates additional complexity,
which unfortunately sneaks its way everywhere where specfiles are handled.
The proper solution to this issue is to make fedpkg import understand both processed and unprocessed specfiles.
rpkg#641 is tracking that work.

@neil do you still want to keep this pull request open?
I appreciate the effort, and the problem is real and serious,
but it looks like the solution will be different than described here.
Alternatively, we can update this merge reuqest document the current complicated situation,
then update again when a proper solution is in place.

I think let's close this for now. I have it on my list to look into
(somehow) soon, but I have been traveling (Fosdem, holiday) the last couple
weeks so have not had a chance to circle back on this.

Thank you

On Thu, Feb 9, 2023, 09:25 Otto Liljalaakso pagure@pagure.io wrote:

oturpe commented on the pull-request: Add note about conflict between rpmautospec andfedpkg importthat you are following:
For all the good things rpmautospec brings,
the specfile conversion creates additional complexity,
which unfortunately sneaks its way everywhere where specfiles are handled.
The proper solution to this issue is to make fedpkg import understand
both processed and unprocessed specfiles.
rpkg#641 is tracking that work.

@neil do you still want to keep this pull request open?
I appreciate the effort, and the problem is real and serious,
but it looks like the solution will be different than described here.
Alternatively, we can update this merge reuqest document the current
complicated situation,
then update again when a proper solution is in place.
``

To reply, visit the link below or just reply to this email
https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/108