#142 Koji build fails on epel8 for netdata package
Closed: Fixed a year ago by tdawson. Opened 2 years ago by tartare.

All my epel8 jobs fail with the following error.
No matching package to install: 'Judy-devel'
In the paste, I opened a ticket here to solve the problem and it was working again. Unfortunately, the same error came back.

See https://kojipkgs.fedoraproject.org//work/tasks/522/80280522/root.log

Thanks for the help

Didier.


Can you please give the top level koji task this was associated with. It will be easier to track down any issues with proxies and such with that.

If you look at the last time that it was successfully built for RHEL8, the Judy that was installed was from a module.
https://koji.fedoraproject.org/koji/buildinfo?buildID=1741029

So, the question is, which module is it from? Is that module a default module? If it is, why are we not seeing it.

It is in the mariadb-devel module which grobisplitter makes into a flat repository. I spent most of yesterday trying to figure out if there was a problem with this but it may be that we have a bug in grobisplitter OR we have reached the limits of what grobisplitter could do and we are going to have to find a new tool or fix.

  1. None of the CRB modules are default modules so when we split that repository, that flag has to be turned off or we would not have any of the modules for virt, python or mariadb. The problem is that because they are not defaults, we are getting duplicates so we end up with
mariadb-devel:10.3:8010020190902091509:cdc1202b:x86_64/
mariadb-devel:10.3:8030020210324132345:229f0a1c:x86_64/
python38-devel:3.8:8020020200309184510:bbc63041:x86_64/
python38-devel:3.8:8040020210420090415:6dfe838a:x86_64/
python38-devel:3.8:8050020210811101222:e3d35cca:x86_64/
python39-devel:3.9:8040020210325151438:f1d9d306:x86_64/
python39-devel:3.9:8050020210811100211:d428a79b:x86_64/
virt-devel:rhel:8000020190828150510:f8e95b4e:x86_64/
virt-devel:rhel:8010020190916153839:cdc1202b:x86_64/
virt-devel:rhel:8010020191202185848:c27ad7f8:x86_64/
virt-devel:rhel:8010020191216093608:c27ad7f8:x86_64/
virt-devel:rhel:8010020200304114113:c27ad7f8:x86_64/
virt-devel:rhel:8020020200316135718:6a468ee4:x86_64/
virt-devel:rhel:8020020200601195459:4cda2c84:x86_64/
virt-devel:rhel:8020020200909224913:4cda2c84:x86_64/
virt-devel:rhel:8030020200909014558:30b713e6:x86_64/
virt-devel:rhel:8030020201123162111:229f0a1c:x86_64/
virt-devel:rhel:8030020210205201602:229f0a1c:x86_64/
virt-devel:rhel:8030020210210212009:229f0a1c:x86_64/
virt-devel:rhel:8030020210323115319:229f0a1c:x86_64/
virt-devel:rhel:8040020210317013608:9f9e2e7e:x86_64/
virt-devel:rhel:8040020210721215855:522a0ee4:x86_64/
virt-devel:rhel:8050020211001230723:b4937e53:x86_64/
virt-devel:rhel:8050020211203195115:c5368500:x86_64/
virt-devel:rhel:820190226174025:9edba152:x86_64/

Most of the time this is ok because they upped all the values in the packages. However Judy-devel was not upped in the last module rebuild so we have duplicates:

mariadb-devel:10.3:8010020190902091509:cdc1202b:x86_64/Judy-devel-1.0.5-18.module+el8+2765+cfa4f87b.i686.rpm
mariadb-devel:10.3:8010020190902091509:cdc1202b:x86_64/Judy-devel-1.0.5-18.module+el8+2765+cfa4f87b.x86_64.rpm
mariadb-devel:10.3:8030020210324132345:229f0a1c:x86_64/Judy-devel-1.0.5-18.module+el8+2765+cfa4f87b.i686.rpm
mariadb-devel:10.3:8030020210324132345:229f0a1c:x86_64/Judy-devel-1.0.5-18.module+el8+2765+cfa4f87b.x86_64.rpm

I don't know if this is the issue as we have multiple copies of python packages and virt-devel packages of the same NVR. However it is confusing and not what i was expecting when trying to debug this. If we force grobisplitter to do default modules on CRB then the following modules go away:

  name: javapackages-tools
  name: mariadb-devel
  name: python38-devel
  name: python39-devel
  name: virt-devel

that contains a good many rpms for python and java tools. At this point of dealing with this fallout, I am at the point of going back to SCL's.

Thanks for your replies

What can be done to work around this behaviour ?

I successfully built netdata with mock after adding config_opts['module_enable'] = ['mariadb-devel'] in /etc/mock/templates/centos-8.tpl and in copr after adding module mariadb-devel:10.3

This is a Fedora releng issue at this point to figure out what the problem is with koji. @tdawson I don't have any idea what to do.

What we need to do for fix netdata build for epel8? We are currently outdated for more than year
Thanks

You need Judy-devel.
Judy-devel is no longer provided by RHEL 8. That is very unusual.
At this point, you need to open a bug against RHEL 8.
This situation is different than many of the other missing -devel packages, because it once was in the release, but here is the documentation for missing -devel packages.
https://docs.fedoraproject.org/en-US/epel/epel-policy-missing-sub-packages/#missing_built_sub-packages

netdata has been building on koji for epel8 for several months.
Closing issue.

Metadata Update from @tdawson:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

a year ago

Login to comment on this ticket.

Metadata