DevHeads.net

mass rebuild, glusterfs build failed

hmmm. from the root.log

DEBUG util.py:585: BUILDSTDERR: Error:
DEBUG util.py:585: BUILDSTDERR: Problem: conflicting requests
DEBUG util.py:585: BUILDSTDERR: - nothing provides kernel >= 4.18.0
needed by firewalld-0.6.4-1.fc31.noarch

how to deal with this? Wait for a new firewalld package?

Comments

Re: mass rebuild, glusterfs build failed

By Kevin Fenzi at 07/26/2019 - 13:29

On 7/25/19 11:05 AM, Kaleb Keithley wrote:
Yep.

I have asked the 'dropping i686 kernels' change owner to file bugs on
these packages.

Looks like:

firewalld-0.7.1-1.fc31.src.rpm
libguestfs-1.40.2-6.fc31.src.rpm
mod_selinux-2.4.4-13.fc30.src.rpm
netlabel_tools-0.30.0-6.fc30.src.rpm
qemu-sanity-check-1.1.5-11.fc30.src.rpm
wireless-regdb-2019.06.03-1.fc31.src.rpm

kevin

Re: mass rebuild, glusterfs build failed

By Kaleb S. KEITHLEY at 07/31/2019 - 15:01

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1733602" title="https://bugzilla.redhat.com/show_bug.cgi?id=1733602">https://bugzilla.redhat.com/show_bug.cgi?id=1733602</a>

One of the suggestions there is to "drop the arch." I.e. i686.

If that ends up being the solution that pretty much would force me to drop
the arch too for glusterfs. (GlusterFS has a bit of plumbing around opening
ports in the firewall. It might just fail — silently or not so silently.
It's hard to know, nobody has tested it.

I suspect dropping the arch might cause some amount of heartache in some
circles.

OTOH, I haven't paid close enough attention to really understand what it
means to stop building i686 kernels. Does that mean no Fedora distribution
for i686 hardware? Does it even make sense to keep building glusterfs for
i686?

Re: mass rebuild, glusterfs build failed

By Kevin Fenzi at 07/31/2019 - 15:42

I would drop the kernel dependency. It doesn't make sense already in
some contexts (containers) and this is a Fedora package for Fedora
users, so I think anyone who would install it would have a kernel, and
if it's a supported Fedora release it would be larger than 4.18.0.

Dropping i686 kernels just means there's no more media/images for i686,
but we keep building everything in case we need it for multilib.
I would assume now you should keep building things, and if there's a
change down the road to limit the scope of i686 more you could drop it
when/if it makes sense then.

kevin

Re: mass rebuild, glusterfs build failed

By Kaleb S. KEITHLEY at 08/01/2019 - 08:35

glusterfs is not the package with the dependency on kernel. Its dependency
is on firewalld, which is where the kernel dependency comes from.

The firewalld packager doesn't seem to know how to add an ExcludeArch: to
the .spec or how to remove the 'Requires: kernel ...' line.

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1733602" title="https://bugzilla.redhat.com/show_bug.cgi?id=1733602">https://bugzilla.redhat.com/show_bug.cgi?id=1733602</a>

Maybe someone with some authority on the subject can give some guidance?

Personally I'd be perfectly happy to stop building glusterfs for 32-bit
platforms. I honestly don't think anyone runs on 32-bit and the developers
aren't really thinking about 32-bit as they work on it. (I had to add a
32-bit build in the CI just to catch all the 32-bit sprintf format mistakes
they were making.)

And FWIW, Ceph has abandoned 32-bit platforms starting with
Nautilus/14.x.x. I have suggested that GlusterFS officially abandon 32-bit
starting with 7.0. Not sure whether that hasn't fallen on deaf ears.

Re: mass rebuild, glusterfs build failed

By Jason L Tibbitts III at 08/01/2019 - 11:11

KK> The firewalld packager doesn't seem to know how to add an
KK> ExcludeArch: to the .spec or how to remove the 'Requires: kernel
KK> ...' line.

KK> <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1733602" title="https://bugzilla.redhat.com/show_bug.cgi?id=1733602">https://bugzilla.redhat.com/show_bug.cgi?id=1733602</a>

KK> Maybe someone with some authority on the subject can give some
KK> guidance?

I did so yesterday and I believe the matter has been resolved (pending
builds and such, of course). The dependency was there because firewalld
required certain kernel features. It should have been either a conflict
or a Boolean dependency instead of a hard dependency, but for f30+ it's
not necessary at all and so has been removed.

- J<

Re: mass rebuild, glusterfs build failed

By Fabio Valentini at 07/26/2019 - 14:58

On Fri, Jul 26, 2019 at 8:19 PM Kevin Fenzi < ... at scrye dot com> wrote:
gsignond rebuild is also affected because of ecryptfs:

Error:
Problem: package ecryptfs-utils-devel-111-18.fc31.i686 requires
libecryptfs.so.1, but none of the providers can be installed
- package ecryptfs-utils-devel-111-18.fc31.i686 requires
ecryptfs-utils = 111-18.fc31, but none of the providers can be
installed
- conflicting requests
- nothing provides kernel-modules needed by ecryptfs-utils-111-18.fc31.i686

Fabio

Re: mass rebuild, glusterfs build failed

By Zbigniew =?utf-... at 07/27/2019 - 08:17

On Fri, Jul 26, 2019 at 08:58:11PM +0200, Fabio Valentini wrote:
Dependencies on kernel packages are pointless. Kernels are multi-install,
so even having a kernel package in the right version doesn't mean that
it is running. Additionally there are various environments (e.g. containers)
where the kernel is provided externally, without the kernel package being
installed. firewalld.rpm should just drop the dependency.

That's even more pointless here.

Zbyszek