#28 rpkg possibly creates Python tarball with incorrect directory inside
Closed 3 years ago by clime. Opened 3 years ago by andymaier.

I am trying to build a SRPM using COPR for a Python package, and rpkg creates what I think is an incorrectly created tarball for inclusion into the SRPM.

The package in COPR is here: https://copr.fedorainfracloud.org/coprs/andymaier/python-nocaselist/package/python-nocaselist/

The COPR package is set up to use rpkg for building, i.e. with these settings in COPR:

Source Type: Build from an SCM repository
SCM type: git
Clone URL: https://github.com/pywbem/nocaselist
Committish: andy/fedora-packaging
Subdirectory: .
Path to .spec file: packaging/fedora/python-nocaselist.spec
Build SRPM with: rpkg

When COPR invokes rpmbuild, it fails when unpacking the nocaselist-1.0.2.tar.gz file and trying to cd into its nocaselist-1.0.2 directory, because that tarball has been created to contain its content below a python-nocaselist-1.0.2 directory, and not the expected nocaselist-1.0.2 directory. The error is shown at the end of this log file: https://download.copr.fedorainfracloud.org/results/andymaier/python-nocaselist/fedora-rawhide-x86_64/01673307-python-nocaselist/builder-live.log.gz

I must admit that I don't fully understand how the tools invoke each other, but later COPR runs from the copr-cli command using a locally built tarball succeed, and only when I use the build with rpkg described above, it fails.


Hello, i am sorry for delay, I have noticed the issue just now.

I think this is caused by auto_packing feature of rpkg v2. It runs quite silly analysis on files at https://github.com/pywbem/nocaselist/tree/andy/fedora-packaging/packaging/fedora and if it finds something which isn't a spec, README or patch, it thinks the directory contain source code and should be automatically packed.

If you removed Makefile and python-nocaselist-1.0.2-1.fc34.src.rpm from the repository, then it would probably work. auto_packing is a deprecated feature but still used right now...

Hello, I will close this for now but if you discover some further problems, please, let me know :).

Metadata Update from @clime:
- Issue status updated to: Closed (was: Open)

3 years ago

Login to comment on this ticket.

Metadata