-
Notifications
You must be signed in to change notification settings - Fork 236
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
Mock as tool to prepare container image with rpm-build only #1482
Comments
There's the new |
praiskup
added a commit
to praiskup/mock
that referenced
this issue
Oct 22, 2024
praiskup
added a commit
to praiskup/mock
that referenced
this issue
Oct 22, 2024
praiskup
added a commit
to praiskup/mock
that referenced
this issue
Oct 29, 2024
praiskup
added a commit
to praiskup/mock
that referenced
this issue
Oct 29, 2024
praiskup
added a commit
to praiskup/mock
that referenced
this issue
Oct 29, 2024
praiskup
added a commit
to praiskup/mock
that referenced
this issue
Oct 31, 2024
praiskup
added a commit
to praiskup/mock
that referenced
this issue
Dec 11, 2024
praiskup
added a commit
to praiskup/mock
that referenced
this issue
Dec 12, 2024
The --enable-plugin=export_buildroot_image option automatically wraps the <chroot>/root directory as OCI-image-as-tarball file, and stores it into Mock's resultdir. We exclude the /builddir/build directory from the generated image; it could contain RPMs, SRPMs, extracted sources, etc. Relates: rpm-software-management#1482
praiskup
added a commit
to praiskup/mock
that referenced
this issue
Dec 12, 2024
We plan to use the podman.py "library" for buildroot (not just bootstrap) logic, too. Let's make it chroot agnostic. Relates: rpm-software-management#1482
praiskup
added a commit
to praiskup/mock
that referenced
this issue
Dec 12, 2024
The --enable-plugin=export_buildroot_image option automatically wraps the <chroot>/root directory as OCI-image-as-tarball file, and stores it into Mock's resultdir. We exclude the /builddir/build directory from the generated image; it could contain RPMs, SRPMs, extracted sources, etc. Relates: rpm-software-management#1482
praiskup
added a commit
to praiskup/mock
that referenced
this issue
Dec 12, 2024
We plan to use the podman.py "library" for buildroot (not just bootstrap) logic, too. Let's make it chroot agnostic. Relates: rpm-software-management#1482
praiskup
added a commit
to praiskup/mock
that referenced
this issue
Dec 12, 2024
For now we can do this with: --buildroot-image registry.fedoraproject.org/fedora:41 --buildroot-image /path/to/a/tarball.tar This commit generalizes the logic for working with bootstrap image so it can work the same both with bootstrap and buildroot images. Fixes: rpm-software-management#1159 Fixes: rpm-software-management#1482
praiskup
added a commit
to praiskup/mock
that referenced
this issue
Dec 14, 2024
We plan to use the podman.py "library" for buildroot (not just bootstrap) logic, too. Let's make it chroot agnostic. Relates: rpm-software-management#1482
praiskup
added a commit
to praiskup/mock
that referenced
this issue
Dec 14, 2024
For now we can do this with: --buildroot-image registry.fedoraproject.org/fedora:41 --buildroot-image /path/to/a/tarball.tar This commit generalizes the logic for working with bootstrap image so it can work the same both with bootstrap and buildroot images. Fixes: rpm-software-management#1159 Fixes: rpm-software-management#1482
praiskup
added a commit
to praiskup/mock
that referenced
this issue
Dec 14, 2024
We plan to use the podman.py "library" for buildroot (not just bootstrap) logic, too. Let's make it chroot agnostic. Relates: rpm-software-management#1482
praiskup
added a commit
to praiskup/mock
that referenced
this issue
Dec 14, 2024
For now we can do this with: --buildroot-image registry.fedoraproject.org/fedora:41 --buildroot-image /path/to/a/tarball.tar This commit generalizes the logic for working with bootstrap image so it can work the same both with bootstrap and buildroot images. Fixes: rpm-software-management#1159 Fixes: rpm-software-management#1482
praiskup
added a commit
to praiskup/mock
that referenced
this issue
Dec 14, 2024
For now we can do this with: --buildroot-image registry.fedoraproject.org/fedora:41 --buildroot-image /path/to/a/tarball.tar This commit generalizes the logic for working with bootstrap image so it can work the same both with bootstrap and buildroot images. Fixes: rpm-software-management#1159 Fixes: rpm-software-management#1482
praiskup
added a commit
to praiskup/mock
that referenced
this issue
Dec 14, 2024
For now we can do this with: --buildroot-image registry.fedoraproject.org/fedora:41 --buildroot-image /path/to/a/tarball.tar This commit generalizes the logic for working with bootstrap image so it can work the same both with bootstrap and buildroot images. Fixes: rpm-software-management#1159 Fixes: rpm-software-management#1482
praiskup
added a commit
to praiskup/mock
that referenced
this issue
Dec 14, 2024
For now we can do this with: --buildroot-image registry.fedoraproject.org/fedora:41 --buildroot-image /path/to/a/tarball.tar This commit generalizes the logic for working with bootstrap image so it can work the same both with bootstrap and buildroot images. Fixes: rpm-software-management#1159 Fixes: rpm-software-management#1482
xsuchy
pushed a commit
that referenced
this issue
Dec 16, 2024
We plan to use the podman.py "library" for buildroot (not just bootstrap) logic, too. Let's make it chroot agnostic. Relates: #1482
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Short description of the problem
Mock nowadays prepares a buildroot environment and then calls
rpmbuild
inside this environment. It would be useful if we could separate these two steps and use Mock to prepare the environment and create the container image. Optionally upload this container image to a registry.This container has resolved and installed build dependencies and installed rpm-build. And it can be consumed by other tooling or by another Mock command (described in #1159)
This image should be created in the
prebuild
phase. We should likely create a new phase, e.g.,preimage_create
.And I think we should allow the user to stop after the image is created and not continue with the rest of the build process.
The text was updated successfully, but these errors were encountered: