How to add <package_name>.rpmlintrc to Fedora dist git repository

I would like to add an rpmlintrc file to filter out spelling errors to the fedora dist git repository as described here: dist.rpmlint.

I tried: git add <package_name>.rpmlintrc

but when I imported the sources using:
fedpkg import source_rpm

fedpkg deleted the file and issued the following message:
Removing no longer used file: <package_name>.rpmlintrc

How do I add the *.rpmlintrc and why is fedpkg deleting it?


This message is actually coming from rpkg, so I took a look at the sources. As it seems to basically set the state of the repository to match the SRPM (removing any files not in the SRPM), I think you could basically work around it by importing the source rpm and then adding the rpmlintrc.

Thanks for the quick reply. I agree that might do it, but I’m concerned what happens the next time I use fedpkg to import a new source file. I created a ticket for the fedpkg folks to comment here: RFE: fedpkg import SRPM handles <package_name>.rpmlintrc

I believe the rpmlintrc option is a great way to get rid of all the invalid rpmlint chatter so you can concentrate on real issues - and as more people learn about it, it will probably be used more often - so there probably should be an approved way to do this rather than trying to hack around the process.

1 Like

I mean, import seems to explicitly delete any files not part of the source rpm. I’m guessing the idea is that the state of the Git repository should be identical to the srpm contents. Maybe you could include the rpmlint file in the srpm somehow?

That being said, at minimum there’s definitely a documentation issue here, since fedpkg’s man page makes no mention of import potentially deleting anything.

Also the bug should probably be on rpkg since that’s the tool that actually handles this…

Noted. I’ll give the fedpkg folks time to respond. They need to be aware of how their tool is behaving. I’ve also referenced this discussion in the ticket - so hopefully they’ll take time to browse input here.

1 Like

If you want it to be included in fedpkg import, just add it as a Source in the rpm spec so that it’s bundled in the SRPM…

Alternatively, after fedpkg import, you can put the file into the git repo, do git add <pkg>.rpmlintrc, then git commit --amend, and finally fedpkg push.

If I add it as a source file don’t I need to package it?

And if I use git commit won’t fedpkg import just delete it next time it is run?

Why would you need to run import again?

When I upgrade the package to the next release.

Yes, but why? You can just commit the spec (+ sources) directly after you’ve updated it. There’s no need for an srpm.

You’re mis-understanding. I use fedpkg import srpm to import the sources.
If I do what you suggest and hack it by just adding the rpmlintrc afterward then
when a new release of the package comes out, and I use fedpkg import srpm to
import the updated sources, I then have to hack it again because fedpkg import will delete
the file again.

I suppose I could investigate adding it as a SOURCE file in the rpm and then perhaps
loading it into the lookaside buffer. The issue is the documentation says you can do it, but
doesn’t at all address HOW to do it.

No, you’re misunderstading me. I’m not talking about the first time. I’m talking about the second, third, etc. times. The workflow for updates does not require using import.

Read this thread:

The documentation is poorly worded. The recommendation which I have been following since has been to use fedpkg import srpm.

Once I get the solution to this rpmlintrc issue, I’m going to revise the documentation myself and run it up through the packaging committee for approval.

“new-sources” should not be mentioned in basic documentation. These
should be added via means of “fedpkg import package.srpm”.

The workflow for new package is then:

$ fedpkg import mypackage.srpm
$ git commit -m "initial import"

and for updated package:

$ git add -u
$ fedpkg clog
$ git commit -F clog
$ fedpkg import updated.srpm
$ git commit --am

This way, the question if the file is stored in lookaside cache or git
is done by fedpkg. Also please note that the “import” command removes
patches which are not used any longer (not sure if it adds new patches …).

fedpkg import currently "extracts sources, patches, and the spec file from an srpm
and update the current module accordingly. It will import to the current branch by default.

Since more people are beginning to use .rpmlintrc it should handle that also. As I mentioned above, I can probably add it as an additional source in the spec file, put it in the fedpkg directory, run the build which should pull it into the srpm. Then I suppose fedpkg will treat it as an additional source file and store it in the lookaside. So, it wouldn’t be included in the source tarball, nor would it handled by git add - and it would be pulled into subsequent builds via fedpkg sources.

This method works - not sure rpmlintrc meets the definition of a source file, but fedpkg appears to handle it just fine:

I’ve asked the maintainers of fedpkg to comment in the bug report referenced earlier - once I get some feedback, I’ll update the documentation.

  1. Add an additional source statement in the spec file: Source1: <>.rpmlintrc
  2. Place the <>.rpmlintrc file in the local fedpkg <> directory
  3. Create srpm: fedpkg srpm
  4. $ git add -u
  5. $ fedpkg clog
  6. $ git commit -F clog
  7. $ fedpkg import updated.srpm
fedpkg responds:
diff --git a/<>.rpmlintrc b/<>.rpmlintrc
new file mode 100644
index 0000000..ea84abe
--- /dev/null
+++ b/<>.rpmlintrc
@@ -0,0 +1,3 @@
+addFilter(r" spelling-error .* (word)"
+addFilter(r" no-manual-page-for-binary <>")
New content staged and new sources uploaded.
Commit if happy or revert with: 'git reset --hard HEAD' (warning: it reverts also eventual user changes).
  1. $ git commit --am

It is slightly poorly worded. But the response you’re advocating is IMHO complete overkill. It can be reworded to make it clear that upstream source tarballs shouldn’t be added to the repo, WITHOUT adding this unnecessary SRPM complication.

Gotta be honest, I firmly hope it’s rejected.

That’s nonsense, frankly.

Upstream sources are not distributed in SRPM form. Those sources need to be retrieved and incorporated into our packaging. If someone chooses to do that by creating an intermediate SRPM to hold their changes, that’s fine, but why should it be required or even recommended that everyone jump through all of those hoops?

What Vit’s advocating for is a terrible use of version control IMHO (something Zbigniew’s question attempts to get at), and makes the packager jump through additional hoops in constructing the SRPM effectively out-of-band. I think you’ll find Vit’s position a minority view of the correct process.

The purpose of the pagure repo is to manage the metapackaging data from which the SRPM will be created. It’s meant to be managed by the packager in whatever way they’re comfortable.

I don’t see how it is overkill, you’re actually typing less commands by using a function that is already built into fedpkg - and I find that method easier to use. If you prefer the other way, that’s fine.

I don’t see the hoops. If you’re following the procedure as written in the Fedora Maintenance Guide, you’ve already built the SRPM at that point and it includes the upstream source - so why not just take advantage of the fedpkg import function. Again, if you want to enter the other commands manually to achieve the same end result that’s fine - but if the feature is built into fedpkg IMHO you should take advantage of it.