minimization/content-resolver-input

Configuration files for Feedback Pipeline

content-resolver-input's Issues

Get back the history!

7db4312

This ^^ is shocking! Really? There is a lot of business value in the history. It is the source of information why we included or excluded something and it has been dropped just with snap of the finger due to "significantly speed up cloning of this repo." I really can't believe this.

Provide number of listed packages.

Looking at buildroot content, it would be nice to know how many packages are listed there, especially when some filter is applied. This would allow to roughly estimate e.g. how many "ruby" packages are there and what is the trend.

python-sphinx is unwanted but we maintain it willingly in CRB

I've noticed on https://tiny.distro.builders/view-srpm--view-eln--python-sphinx.html that this package is marked as unwanted because it is in "Unwanted SELinux packages".

Yet we (cs_apps python-maint) maintain this package willingly and deliberately in CRB (see e.g. #399 where it was listed).

What shall be done about this situation?

cc @bachradsusi @torsava

ELN Buildroot and ELN Prototype Buildroot

As I mentioned on IRC, I've added the ELN set based on the ELN repos. So we'll have:

• Rawhide-based ELN Prototype
• Rawhide-based ELN + Buildroot Prototype
• ELN Package Set
• ELN Package Set + Buildroot

We'll now need two different workloads with buildroot. One for the prototype, one for the other.

They'll each need to use a different label so they're put in right place.

• For Rawhide-based ELN Prototype it's eln-buildroot-prototype
• For ELN Package Set it's eln-buildroot

Remove "independent" rubygems package from build

Looking at [1], rubygems package is marked as unwanted but available. The problem with this packages is, that in Fedora, there is rubygems package [2], but there is also rubygems subpackage of ruby package [3], which should be enough to satisfy all ELN needs. Please drop the rubygems package and improve the content-resolver to properly handle scenarios like this.

Is libb2 unwanted?

Hello, in https://src.fedoraproject.org/rpms/python3.12/pull-request/63 @yselkowitz says:

Standalone libb2 is unwanted in RHEL.

However, this is not marked as unwanted here.

Is it unwanted or is it not unwanted?

If it is actually unwanted, could you please mark it as such?

Thanks.

Update audio playback workload for ELN/c10s?

@csoriano1618 a couple questions regarding the audio playback workload:

• can openal-soft be dropped from ELN? qt5 is being replaced by qt6, which only uses it on the WebAssembly platform, so after https://src.fedoraproject.org/rpms/qt6-qtmultimedia/pull-request/2 nothing in ELN will depend upon it.
• Is the pulseaudio daemon still wanted in RHEL 10, or should pulseaudio be switched to pipewire-pulseaudio?

buildroot files should not be in this repo

The buildroot files are causing delays and problems for maintainers to manually change their yaml files, and it is only going to get worse.
I've found it takes between 2 and 5 minutes to simply clone the repo.
When manually editing a yaml file, I often have to re-pull and merge because buildroot has changed.
The git repo is currently at 750M.

All of these problems are going to get worse as time progresses.
We need a different way to get the buildroot information to Content Resolver

Use RHEL9/CentOS stream dependencies for content resolver

It would be nice if content resolver was smart enough to use RHEL9/CentOS stream to resolve its dependencies instead of placeholders. E.g. for git-lfs, there is following placeholder:

content-resolver-input/configs/sst_cs_apps-scm.yaml

Lines 18 to 28 in 253dabe

	package_placeholders:
	git-lfs:
	srpm: git-lfs
	description: Git extension for versioning large files
	requires:
	- git-core
	buildrequires:
	- perl-Digest-SHA
	- perl-Test-Harness
	- git

But it would be much easier, if content resolver knew where to ask RHEL9/CentOS stream for the real values from the package, which is not inherited into ELN.

Outdated content

It seems that the content resolver content is not refreshed for a few weeks:

Compose Date: 2021-05-12 (2 days ago)
Page refreshed at 14 May 2021 15:48 UTC.

checking at:

https://tiny.distro.builders/view-srpm--view-eln--rubygem-tilt.html
https://tiny.distro.builders/view--view-eln.html

Content Resolver should output a comps.xml with Variant split

Since Content Resolver knows all of the packages and their dependencies and it will soon(?) support the Variant split, we should have it automatically generate a comps.xml for the split. It can probably also provide us with a prepopulate.json for the pungi configuration.

Include rubygem-ronn-ng instead of rubygem-ronn which was retired

I wonder how often the dependencies are updated, because rubygem-ronn replaced in Fedora Rawhide by rubygem-ronn-ng, but this was not reflected anywhere and I wonder why?

Update README

The project currently has a large number of yaml files. It would be very helpful if the README outlined:

• What each grouping is for (e.g. rhel-8-appstream-*)
• How they fit together
• What the "top level" projects are (if that's a thing?)
• How contributors should interact and update the yaml files

Content resolver input is not updated

Looking at rubygem-kramdown-parser-gfm, it shows 15 days old content. Can we have the data refreshed?

python2.7, python3.6 and python3.8 still in ELN

Hey ELN people.

Despite my efforts to block python2.7, python3.6 and python3.8 from ELN, I still see that the packages are built there.

Could you please help me understand what needs to be done to prevent that from happening?

I've tried to communicate this in https://lists.fedoraproject.org/archives/list/[email protected]/thread/U4TY26R3S65E474FUKGKB6H4JOCIEITY/ but there was no useful info except one private reply by @sgallagher who suggested that the proper communication channel for this are PRs in this repo.

The relevant PRs were:

• #25
• #35

Later moved around by #68.

ruby 2.6 module builds ruby 2.7

Here is some definition of Ruby 2.6 module:

https://github.com/minimization/content-resolver-input/blob/master/configs/rhel-8-appstream-module-
ruby-2.6.yaml#L8

but it seems it builds Ruby 2.7:

https://tiny.distro.builders/workload--rhel-8-appstream-module-ruby-2.6--fedora-empty-base--repository-fedora-eln--x86_64.html

Remove all unnecessary ruby packages

It would be nice if all ruby package, except those listed in

• sst_cs_apps-ruby-db-connectors.yaml
• sst_cs_apps-ruby-rspec.yaml
• sst_cs_apps-ruby.yaml

are removed. There is not even clear why they are included (probably via transitive dependencies, but hard to tell from the app

Automated comments on PRs don't work

Recently, @regexowl implemented a super helpful test that posts comments to PRs, checking for any potential errors in the configs.

This seemd to work great in all our tests, until someone else sent a PR and the test failed with the following error:

Unhandled error: HttpError: Resource not accessible by integration

It appears that this is a known limitation of GitHub Actions.

If anyone knows any way around this, please let me know!

buildroot-eln.yaml keeps getting reorganized every hour

I've noticed that most of the changes in https://github.com/minimization/content-resolver-input/commits/master/configs/buildroot-eln.yaml are just changing the order of packages. May the packages please be sorted, so the changes are easier to review? Thanks.

Confusing "Perl" SRPM for rubygem-thin

Looking at rubygem-thin, I am not completely sure why there is refered "SRPM perl", that appears to be some error.

How to leverage `bcond_with` macros

It seems there is rubygem-stringex dependency chain pulled in for rubygem-kramdown just to execute 5 test cases for optional and probably rarely used feature. Is there any way to leverage bcond_without stringex feature flag if I going to propose such change to that package?

libradosstriper is "unwanted" but still in comps

libradosstriper-devel and libradosstriper1 are in the RHEL 9 CRB repository.

These are already listed in content-resolver-input/configs/sst_rh_samba_storage-unwanted.yaml. Should I submit a comps XML change directly to https://gitlab.com/redhat/centos-stream/release-engineering/comps/-/blob/main/comps-centos-stream-9.xml.in ?

Remove "rubypick"

rubypick is on the unwanted list. It should be easy to get rid of it, because there is feature flag in the .spec file. The only question is where to put the conditional. Is there possible to set them in Koji tag or is there some macro file with the feature flags? @tdawson

RFE: Send automated notifications to "soon-next-in-line" maintainers

We noted that teams would appreciate being notified they were next in line (or soon to be) for maintaining a package whose dependency another team (so far the maintainer) had dropped. This would ideally be achieved via some automated means based on CR data.

For example: team A is the 3rd in the line of succession to maintain a package. Team Z is the current maintainer and has dropped the dependency. Accordingly, team A is now the 2nd in the line of succession for maintaining the package. Team Y is the likely new maintainer as soon as team Z negotiates it (which probably was already underway).

As such, a notification should be sent to team A alerting it of the new status quo, including the possibility of team Y also looking forward to dropping its dependency and thus request team A to own the package. Team A would then be advised to prepare for that possible state, which could encourage a possible elimination of the dependency as well.

Provide "refresh" date of the content resolver output

Yesterday, I have updated rubygem-rack to drop the rubygem-thin dependency. However, today, the rubygem-thin is still listed as being part of buildroot:

https://tiny.distro.builders/view-buildroot--view-eln--x86_64.html
https://tiny.distro.builders/view-rpm--view-eln--rubygem-thin.html

Providing the "refresh" date would help understand, if there was already chance the change was propagate already or not.

Build preriodically with bootstrap macro enabled.

The packaging guidelines provides a way to bootstrap packages [1]. It would make sense to periodically enable this macro in buildroot to break the loops requiring bootstrapping. That would help with failures such as [2].

Configs moved to a subdir, please adapt square 1

Hi @tdawson, I've moved all the configs to a subdirectory so the repository here on GitHub shows the README better. I know you're pushing the ELN Buildroot workload automatically to this repo. Can you please tweak your script to push it to the configs directory?

new kpatch subpackage coming in rhel-8.4, 9.0

Hi, the kpatch team intends to introduce a new subpackage to the kpatch package called kpatch-dnf in RHEL-8.4.

We've already added sst_kernel_ft-kpatch.yaml for the main package, will we need update this file if/when a new subpackage is added?

Thanks
-- Joe

cc: @julien-thierry