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

contrib/build_rpm.sh fails on CentOS-8, RHEL-8 and Fedora-31 #6248

Closed
ssbarnea opened this issue May 15, 2020 · 7 comments
Closed

contrib/build_rpm.sh fails on CentOS-8, RHEL-8 and Fedora-31 #6248

ssbarnea opened this issue May 15, 2020 · 7 comments
Assignees
Labels
locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. stale-issue

Comments

@ssbarnea
Copy link
Collaborator

ssbarnea commented May 15, 2020

As reported by RDO 3rdPaty CI jobs that run on each PR and also as periodic on master, the ability to build rpms directly from source on these plaforms got broken somewhere during the last two weeks.

All these jobs are relying on contrib/build_rpm.sh to perform the rpm building so it is fixable from there.

@ssbarnea
Copy link
Collaborator Author

We tried to fix this at CI level via https://review.rdoproject.org/r/#/c/27527/6/playbooks/podman/pre.yaml with good results but we realised that would be a really bad idea, as it would involve hacking the operating system and bringing it to an unsupported status (installing ElRepo repositories).

It is much better to implement these changes directly in contrib/build_rpm.sh where anyone contributing to libpod can use, fix and improve.

@mheon
Copy link
Member

mheon commented Jun 2, 2020

@baude @rhatdan @ssbarnea Is this resolved?

@ssbarnea
Copy link
Collaborator Author

ssbarnea commented Jun 3, 2020

20 days ago it was sorted via CI/CD hacks as I mentioned, but AFAIK nobody spared time to implement these steps into in-repo build_rpm.sh script.

Without libpod cores stepping in and assuring that this happens and no regressions are allowed I doubt we have a sustainable way to keep it alive.

RDO&TripleO can assure that the CI/CD is working, but it cannot prevent regressions with a job that is not-voting.

Looking at https://review.rdoproject.org/zuul/builds?project=containers%2Flibpod&pipeline=openstack-regular I conclude that libpod builds rpms only on fedora-31 and not on rhel-8 or centos-8.

CI is running build_rpm.sh on these platforms where it also has root access, if it fails is almost for sure a fault in libpod.

Sidenote: we did speak about this in our team and we even considered starting to email libpod and post irc notifications on #podman in order to raise awareness.

@rhatdan
Copy link
Member

rhatdan commented Jun 3, 2020

I just ran it and it is failing because we do not install debuginfo in the spec file.
Looking at the build_rpm.sh script , it looks like it does not intend to build them?
I don't see that this is something that we did to cause this, but if it was I am willing to be educated.

@rhatdan
Copy link
Member

rhatdan commented Jun 3, 2020

    Installed (but unpackaged) file(s) found:
   /usr/lib/debug/.dwz/podman-2.0.0-1591179052.gita17bdf7b.fc32.x86_64
   /usr/lib/debug/usr/bin/podman-2.0.0-1591179052.gita17bdf7b.fc32.x86_64.debug
   /usr/lib/debug/usr/bin/podman-remote-2.0.0-1591179052.gita17bdf7b.fc32.x86_64.debug
   /usr/lib/debug/usr/libexec/podman/conmon-2.0.0-1591179052.gita17bdf7b.fc32.x86_64.debug
   /usr/src/debug/podman-2.0.0-1591179052.gita17bdf7b.fc32.x86_64/libpod/lock/shm/shm_lock.c
   /usr/src/debug/podman-2.0.0-1591179052.gita17bdf7b.fc32.x86_64/libpod/lock/shm/shm_lock.go
   /usr/src/debug/podman-2.0.0-1591179052.gita17bdf7b.fc32.x86_64/libpod/lock/shm/shm_lock.h
   /usr/src/debug/podman-2.0.0-1591179052.gita17bdf7b.fc32.x86_64/libpod/oci_attach_linux_cgo.go
   /usr/src/debug/podman-2.0.0-1591179052.gita17bdf7b.fc32.x86_64/pkg/rootless/rootless_linux.c
   /usr/src/debug/podman-2.0.0-1591179052.gita17bdf7b.fc32.x86_64/pkg/rootless/rootless_linux.go
   /usr/src/debug/podman-2.0.0-1591179052.gita17bdf7b.fc32.x86_64/vendor/github.com/containers/storage/drivers/btrfs/btrfs.go
   /usr/src/debug/podman-2.0.0-1591179052.gita17bdf7b.fc32.x86_64/vendor/github.com/containers/storage/pkg/unshare/unshare.c
   /usr/src/debug/podman-2.0.0-1591179052.gita17bdf7b.fc32.x86_64/vendor/github.com/containers/storage/pkg/unshare/unshare_cgo.go
   /usr/src/debug/podman-2.0.0-1591179052.gita17bdf7b.fc32.x86_64/vendor/github.com/coreos/go-systemd/v22/sdjournal/journal.go
   /usr/src/debug/podman-2.0.0-1591179052.gita17bdf7b.fc32.x86_64/vendor/github.com/mtrmac/gpgme/go_gpgme.c
   /usr/src/debug/podman-2.0.0-1591179052.gita17bdf7b.fc32.x86_64/vendor/github.com/mtrmac/gpgme/go_gpgme.h
   /usr/src/debug/podman-2.0.0-1591179052.gita17bdf7b.fc32.x86_64/vendor/github.com/seccomp/libseccomp-golang/seccomp_internal.go

@rhatdan
Copy link
Member

rhatdan commented Jun 3, 2020

Ok I just looked at the failures on centos7, centos8 and rhel8.

We are not planning on shipping any more centos7/rhel7 versions, so these tests should be removed.

The failures are all caused because we are relying on newer versions of OCI Runtimes to add a provides ociruntime to their specfile. runc, crun, kata should all provide this. That would allow podman to run with any runtime. When we release rhel8.3 we will make sure the OCI Runtimes have the proper provides. For now, we can dumb down the spec file to force the use of runc.

@github-actions
Copy link

github-actions bot commented Jul 4, 2020

A friendly reminder that this issue had no activity for 30 days.

@rhatdan rhatdan closed this as completed Jul 6, 2020
@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 23, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. stale-issue
Projects
None yet
Development

No branches or pull requests

4 participants