[Spacewalk-list] Missing group (comps.xml) information with Fedora 22

[Brian Buesker]

I recently upgraded our spacewalk server to version 2.4 since that
version officially supports Fedora 22. I had previously created a Fedora
22 distribution (when my spacewalk server was still running 2.3) and
created a channel that I synced with the Fedora 22 Everything
repository. This sync indicated it was able to fetch the comps file.

    Linking packages to channel.
    Repo
    http://mirror.pnl.gov/fedora/linux/releases/22/Everything/x86_64/os/
    has comps file
    1b6e2afe599e5969f9c6e50bad1bf85e2ab23929500e08a4d006330da602fdc4-comps-f22.xml.xz.
    Repo
    http://mirror.pnl.gov/fedora/linux/releases/22/Everything/x86_64/os/
    has 0 errata.
    Sync completed.
    Total time: 1 day, 11:32:17

I also confirmed that this the comps file is present on the file system
as well as in the database.

When I went to install a machine, I found that both during kickstart and
during normal operation that the group information (provided by
comps.xml) does not seem to be available. During kickstart, I saw the
xz-compressed comps.xml file in the dnf cache directory (but not the
uncompressed one), but still received an error for each package group my
kickstart file specified.

After kickstart, I found that neither the compressed nor uncompressed
files were present in the dnf cache directory. All dnf groupinstall
operations fail with no such group and a dnf grouplist indicates there
is no group data available in the repositories.

After poking around in the dnf and librepo code, I think I may have a
clue as to why this is happening. The dnf python code is constructing a
librepo Handle that sets the file whitelist to only include the
compressed form of the groups ("groups_gz"). See how yumdlist gets
initialized in the repo module within dnf. Since it appears the
repomd.xml provided by Spacewalk only includes the uncompressed groups
file, librepo never ends up downloading the groups file and thus it is
not available for dnf operations.

At this point I think I'll be able to work around this by a combination
of a pre-nochroot script that updates this variable to include "group"
and then a patched dnf RPM that fixes this. With that said, are there
any plans in a future Spacewalk version to fix it so that it includes
both the group and group_gz types?

Thanks,
Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20160111/1eaa335c/attachment.htm>