Most bootloaders used in Fedora already have BootLoaderSpec, but extlinux
doesn't yet. So when using extlinux the old grubby must to be installed.
The grubby-deprecated package was added to the @arm-tools group to ensure
that it will be installed on ARMv7 machines. But on aarch64 machines this
group can also be installed, which means that grubby-deprecated will be
leading to Anaconda disabling the BLS support.
Instead, the right place to solve this is in Anaconda which already does
install grubby-deprecated when the extlinux bootloader option is chosen.
That way grubby-deprecated will only be installed for ARMv7 machines, but
won't be installed in aarch64 machines that use grub2 EFI and support BLS.
Resolves: rhbz#1678843
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Migen enables hardware designers to take advantage of the richness of
Python (object oriented programming, function parameters, generators,
operator overloading, libraries, etc.), to build well organized, reusable
and elegant digital hardware designs.
Also see https://src.fedoraproject.org/rpms/python-migen
Signed-off-by: Gabriel Somlo <gsomlo@gmail.com>
Add the terminus-fonts-grub2 package containing the Terminus font
in the Grub2 font format (used for Grub2 themes) to the legacy-fonts
group, as the https://fedoraproject.org/wiki/Packaging:FontsPolicy
requires.
With BLS the grubby tool isn't used when new kernels are installed, since
the bootloader config files don't have to be edited anymore. But u-boot
doesn't have BLS support yet, so on ARMv7 installs the old grubby tool
needs to be installed.
That's why commit 4c2694e1d8 ("Move grubby and grubby-deprecated from
@core to @arm-tools") moved the grubby-depracted package to @arm-tools.
But it also moved the grubby package and while this isn't needed during
install on other arches, it may be useful for users to manage their boot
menu entries.
Suggested-by: Adam Williamson <awilliam@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Adding them into @core was supposed to make them show up in some
install trees, according to the commit message, but it broke
regular BLS installs:
https://bugzilla.redhat.com/show_bug.cgi?id=1654036
which is obviously a major problem. I *think* moving the entries
to arm-tools should ensure the packages are in the relevant trees
without breaking BLS installs.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
For https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot.
glibc has Requires:glibc-langpack and Suggests:glibc-all-langpacks.
glibc-minimal-langpack has Provides:glibc-langpack, so if it is explicitly
pulled in, glibc-all-langpacks will not be installed (unless it is pulled in
through some other means).
Uses of (LANG|LC_.*)=.._..\.(UTF-8|utf8) have been either removed, or updated to
C.UTF-8, or BuildRequires: glibc-langpack-.. have been added, so it should be
OK to do this change now.
Signed-off-by: Stephen Gallagher <sgallagh@redhat.com>
If they are "mandatory", then attempting to install them atop a
system installed with another variant generates a conflict. A
"default" package gets ignored by DNF.
This patch is a pre-requisite to a larger effort to simplify the
variant handling in the fedora-release package.
Signed-off-by: Stephen Gallagher <sgallagh@redhat.com>
As per the previous batch, fix more references to packages that
don't exist. This should cover all the remaining 'not found on
any arch' cases. Again I tried to check the reason for all cases
and provide appropriate replacements where possible.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
There are a lot of comps entries pointing to packages that just
don't exist any more. Note that group installs don't follow
Provides: or Obsoletes: or any of that jazz, the package must
exist under the exact name listed in comps.
This is a first set of fix-ups for these (as I've been working
on it all afternoon and am tired now). I looked into the reason
why every single one does not exist any more. Some had obvious
replacements, so I used them. Some did not, so I just took them
out. These are all packages that no longer exist on *any* arch,
I'm dealing with the 'package exists on only some arches' entries
later.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It would be nice to make 'package is listed in group, but does
not exist' a fatal error (at least optionally) for dnf etc, but
we can't really do that at present because it's *not* been a
fatal error for so long that our comps have tons of stale
entries for packages that no longer exist, and also entries that
aren't properly archified for packages which only exist on some
arches. This script pokes through the comps file for current
Rawhide and identifies all (I hope) pkgreqs which specify a
package that is not actually available in current Rawhide, per
arch.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
