It's hard to Flatpak as it needs access to the entire filesystem and
should be included by default so we include it in the base image.
See: https://pagure.io/fedora-kde/SIG/issue/13
There has been no package called just 'qgnomeplatform' for some
time. qgnomeplatform-qt5 used to provide 'qgnomeplatform', but
.fc39 builds onward do not, so now we have a .fc39 build of it,
this breaks.
I'm not sure all these places where we list qgnomeplatform
exactly make sense - we seem to be excluding it in some places
then explicitly pulling it in in others - but this is the
minimal change to fix the immediate problem.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
That said, maybe someone wants to do something else for these
images, but this is kind of the lowest common denominator...
Part of https://pagure.io/releng/issue/11324
The comps group that we are pulling from do not include ncurses and we
explicitely include it in fedora-common-ostree.yaml thus we don't need
to exclude it.
Removing initial-setup in [1] also removed the dependency to Anaconda
and its dependencies.
Re-add some of Anaconda's dependency so that we don't loose support for
RAID, bcache & mobile-broadband-provider-info.
See: [1] https://pagure.io/fedora-kde/SIG/issue/243
Enable fetching packages from multiple comps groups for each desktop.
This is currently unused but this removes the constraints around having
all base packages for a given desktop in a single comps group.
This could also be used to get packages from other groups such as the
input-methods group for example.
This lets the recently-merged improved arch-specific package
support handle all the arch-specific packages which were
previously excluded in `comps-sync-exclude-list.yml` and listed
manually in `fedora-common-ostree.yaml`. As the diff shows,
the sync script now correctly includes the same packages for
the same arches in `fedora-common-ostree-pkgs.yaml`, plus a few
appropriate additions of things that should be there but had
been left out, on ppc64le and aarch64.
We also drop the `packages-armhfp` and `packages-ppc64` lists,
as we no longer build for either of those arches. This allows
us to move `ostree-grub2` into the non-arch-specific list, since
it's no longer left out on any arch we care about.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The rpm-ostree backend in Discover is now in a good shape and should be
ready for wider testing so let's enable it in Rawhide first and then we
will backport it to F37 once Plasma 5.27 lands there.
See: https://pagure.io/fedora-kde/SIG/issue/133
This reverts commit 82989adb2e.
This includes corrections for per-arch packages, thanks to the
improvements to comps-sync.py in the previous commit.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
comps allows for a package to be included in a group only on
specified arches, with a line like this:
<packagereq arch="aarch64,x86_64" type="default">kio-gdrive</packagereq>
up till now, `comps-sync.py` effectively ignored this, treating
such a line exactly the same as this:
<packagereq type="default">kio-gdrive</packagereq>
and attempting to include the package even when building on e.g.
ppc64le.
Solving this is unfortunately tricky due to exactly how libcomps
handles these arch restrictions. It does not expose the list of
arches as a property of each returned 'package' object when you
do a group search. Instead you're supposed to filter the group
search down to the arch(es) you are interested in, and it only
includes the appropriate packages for that arch. So all we can
do is run our queries multiple times, once for each arch we may
wish to build on, keep track of the results per arch as we go,
and do some fancy footwork to keep track of the mapping between
"archful" comps entries and the lists in the YAML files.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
