Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

copr Fedora 40 x86_64 rpmbuild binary broken #3435

Closed
nestire opened this issue Sep 30, 2024 · 5 comments
Closed

copr Fedora 40 x86_64 rpmbuild binary broken #3435

nestire opened this issue Sep 30, 2024 · 5 comments

Comments

@nestire
Copy link

nestire commented Sep 30, 2024

my Build fails with:
/usr/bin/rpmbuild: error while loading shared libraries: libcap.so.2: cannot open shared object file: No such file or directory

build with fedora 41 and fedora 39 works

builder-live.log

@nikromen
Copy link
Member

nikromen commented Oct 7, 2024

Hello, this doesn't seem like copr issue, but honestly I don't know how to fix the build since I have little to no knowledge about software you are trying to build. From the logs it seems like the libcap dependency (the libcap.so.2) wasn't installed - even though I can see it inside your spec file... it could be caused by some other packages inside f40 - since it seems like it's f40 problem? Also the libcap package version differs across fedora versions - https://src.fedoraproject.org/rpms/libcap - so there may be difference between them.

@FrostyX
Copy link
Member

FrostyX commented Oct 7, 2024

It's strange though. When I build the package using Mock, it works.

mock -r fedora-40-x86_64 nitrokey-app2-2.3.2-1.src.rpm --enable-net

But when I try to build it using copr-rpmbuild, it fails

copr-rpmbuild --verbose --drop-resultdir --task-url https://copr.fedorainfracloud.org/backend/get-build-task/8092164-fedora-40-x86_64 --chroot fedora-40-x86_64

Even though with a different error than OP

/bin/sh: error while loading shared libraries: libtinfo.so.6: cannot open shared object file: No such file or directory

@praiskup
Copy link
Member

praiskup commented Oct 7, 2024

Issues like this often happen when some package provides duplicate soname to the one provided by core system. Isn't libpcap.so provided (by mistake) by nitrokey-app2?

@mmerklinger
Copy link

Indeed we provided a duplicate of libcap.so. I'm currently looking into building the package without pyinstaller. We recently did some changes to reduce dependencies. The dependencies were the original reason to build it with pyinstaller. I think we can close this issue.

@praiskup
Copy link
Member

Thank you for the update. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

No branches or pull requests

5 participants