Fedora 30 now includes rpm-4.14.2.1-4.fc30 with support for
ModularityLabel. We're not using the DistTag anywhere anymore and it
should be safe to drop it at this point.
Signed-off-by: Petr Šabata <contyk@redhat.com>
This commit includes the backport of the changes to `krb_login` in
https://pagure.io/koji/pull-request/1187. This change is required
for our separate threads to use a separate Kerberos context per thread.
When using a single Kerberos cache that is shared among threads,
Koji logins start failing because the cache gets corrupt. This uses
the Linux kernel keyring to store a Kerberos cache per MBS thread.
See https://web.mit.edu/kerberos/krb5-1.12/doc/basic/ccache_def.html
MBS calls some read-only Koji APIs which does not require to log into a
session. This patch makes it optional to choose whether to login a
session and use anonymous session properly to call those read-only APIs.
Signed-off-by: Chenxiong Qi <cqi@redhat.com>
This resolve the stream collision by adding specific RPMs to
module-build-macros SRPM as Conflicts.
For more information about module stream collision, please refer to
docstring in utils/ursine.py
Signed-off-by: Chenxiong Qi <cqi@redhat.com>
For some modules, modularity-wg wants to be able to ship the "-devel" modules containing
the RPMs which are normally filtered out from the module.
This PR generates second Koji CG module with -devel suffix in a name with final modulemd
files containing the filtered out RPMs.
During I'm reading through the code base to learn MBS, I found out some
typos and minor issues in some other docstrings, and I also found some
docstrings with extra informative description could make it easier to
understand the code.
Signed-off-by: Chenxiong Qi <cqi@redhat.com>
If a module has filters set and it buildrequires itself, issues occur
during component reuse. In that event, the filtered RPMs from the
previous module build will not be available in the buildroot because the NVRs
in the filters will match the RPMs from the reused component.
Co-authored-by: Jan Kaluza <jkaluza@redhat.com>
This addresses an issue when a module contains builds that have different
names in their NVR than the component name in MBS. This happens with
SCLs for instance. MBS wouldn't be able to find the component to mark
as tagged in the database since it was searching by the wrong name, so the
build would just stall. This uses the NVR now to find the correct build
in the database.
Previously MBS configured all Koji build tags with
repo_include_all=True extra option. But for some modules it was
desired to be able to have tags with repo_include_all=False.
Fixes#957
No reason to hide module context from the consumers, plus it's useful to
keep it in the DISTTAG tag (not to be confused with the %{dist} tag) for
tracking.
The %{disttag} feature will do nothing until RPM supports it. This is
planned in 4.14.2.
See https://bugzilla.redhat.com/show_bug.cgi?id=1596192.
Signed-off-by: Petr Šabata <contyk@redhat.com>
Signed-off-by: Martin Curlej <mcurlej@redhat.com>
Updated PR according to review.
Signed-off-by: Martin Curlej <mcurlej@redhat.com>
Searching by multiple koji tags + tests
Signed-off-by: Martin Curlej <mcurlej@redhat.com>
I discovered that local builds have been broken by recent (good) changes in
dnf. At the end of every batch, we regenerate the local repo with createrepo
and we also call modifyrepo to include the modulemd file as we progress. This
was added in #467.
What we really want, is for the modulemd file to be present at the *end* of the
build.
Recently, dnf started respecting the modulemd file natively, such that builds
we built in batch0 would not show up in batch1. They would be present in the
repo, but they would be marked as belonging to a module which was not enabled,
and so could not be pulled in. Every module build would fail because
module-srpm-macros was in a disabled module (the module being built at the
time).
This change makes it so that the module metadata is only added to the repo at
the very end of the build. I moved it into a `finalize` method on the builder
which the copr builder was using, and for symmetry's sake I moved the koji
content generator code to the same method on that builder.
There was a circular import issue to solve between the koji module builder and
the koji content generator modules that generated a larger diff, but is mostly
cosmetic and mock changes.
Commit 42aef7d5d2 moved the macros installed by module-build-macros
from %_rpmconfdir (which is unaffected by %_prefix) to %_sysconfdir/rpm
(which follows %_prefix). This interacts badly with the Flatpak module
macros which change %_prefix to /app - when flatpak-rpm-macros is
in the buildroot while module-build-macros is built, module-build-macros
installs its macros to /app and they aren't found when building the
rest of the packages in the module.
Hardcoding /etc rather than using %_sysconfdir fixes this.
If the user redefines %_sourcedir in ~/.rpmmacros, `mbs-build local`
will fail trying to build module-build-macros otherwise because rpmbuild
will look for sources -- macros.modules -- in the wrong place.
