{ "action": "new_repo", "branch": "rawhide", "bug_id": "", "description": "", "exception": true, "monitor": "monitoring", "namespace": "rpms", "onboard_packit": "no", "repo": "iniparser-epel", "summary": "", "upstreamurl": "" }
This request wants to skip bugzilla validation! @amedvede @carlwgeorge @churchyard @humaton @ignatenkobrain @jnsamyak @kevin @limb @mohanboddu @patrikp @petersen @releng-bot @tibbs could you check if this is correct? If yes, please respond to this ticket with '@releng-bot valid' comment
I'll add some context to this request in case it is helpful.
iniparser-devel is missing from RHEL10 iniparser package. This is blocking netatalk and ndctl packages in EPEL10.
Per the short term instructions of the EPEL FAQ for missing -devel subpackages, I am requesting iniparser-epel package.
In accordance with the long term instructions, an issue was created here last October: https://issues.redhat.com/browse/RHEL-62928
I have a prototype iniparser-epel package staged on Copr and ready to go. You can review it here if you are interested: https://download.copr.fedorainfracloud.org/results/kni/iniparser-epel/rhel-10-x86_64/09137171-iniparser-epel/iniparser-epel.spec
Carl George's cogl-epel package was used as a template.
I'd advise against this because iniparser-devel is currently slated to move from BUILDROOT to CRB in RHEL-10, at which point it should not be in EPEL. There is an upstream issue open to move iniparser-devel to CRB, but I don't know what the status is there.
https://issues.redhat.com/browse/RHEL-62928
@dcantrell Yes, that is the link I provided in my previous post.
The EPEL packaging guidelines shown here define doing both: https://docs.fedoraproject.org/en-US/epel/epel-faq/#rhel_8_has_binaries_in_the_release_but_is_missing_some_corresponding__devel_package._how_do_i_build_a_package_that_needs_that_missing__devel_package
When/if Redhat ever fixes this on their end, I will retire the package. Since I am willing to do the work (I already did), what exactly is your objection?
Redhat has been sitting on this since last October. It seems silly not to deploy a temporary fix while we wait, especially since the temporary fix is spelled out in the EPEL packaging guidelines.
Sorry, I missed that part about this being a temporary fix until it's fixed in CRB. In that case, I have no objection. Sorry, my fault for misreading/reading quickly.
Understood, and I do appreciate your feedback.
In general this request is ok, and it's somewhat common for us to create *-epel style packages for a short term fix while a CRB devel package request is getting processed. I wish it weren't necessary, but these request do sometimes take far longer than they should. I can approve this dist-git repo, but I have one question first. The reason given is netatalk and ndctl. netatalk is already in EPEL 10, and ndctl is not allowed in EPEL 10 because it's already in CentOS/RHEL 10. If there are other packages that buildrequire iniparser-devel that are blocked by this, I'm happy to approve this and move things forward. But if there are currently no desired packages that are blocked by this, I'd advise just waiting for iniparser-devel to get added to CRB.
Good question. RHEL-62928 was originally opened because of the ndctl build requirements. I didn't realize ndctl was part of rhel, and I guess the original author of that ticket didn't either? That's odd.
You are right netatalk 4.1.2 does indeed exist in rhel10. However, the upstream project has been under a lot of change, and I'd like to keep the rhel10 branch up to date. Iniparser was added as a build requirement in 4.2.0. The latest version of Netatalk is 4.2.4.
Circling back to this issue.... I noticed RHEL-62928 now has a completion target of el10.1 with an eta of November.
Is there any reason why we can't proceed with iniparser-epel for epel10.0? If it matters, I'll put an alert in my calendar to retire the package in October.
Note that netatalk package currently in epel 10.0 has a bug that prevents the service from starting. This is fixed in the latest package.
Can we please move forward with this request??
You are right netatalk 4.1.2 does indeed exist in rhel10. However, the upstream project has been under a lot of change, and I'd like to keep the rhel10 branch up to date.
I'm assuming you mean the epel10 branch here. I'm concerned about upgrading it from 4.1.2 to 4.2.0 or later, because the upstream release notes mention a "range of breaking changes" but doesn't go into further detail about what those breaking changes are. Breaking changes would not be allowed under the EPEL updates policy. Do you happen to know more about what these breaking changes are?
Is there any reason why we can't proceed with iniparser-epel for epel10.0?
New package additions for RHEL take effect for CentOS first, and then show up in the next RHEL minor version. My comps pull request was merged and iniparser-devel is now in CentOS 10 CRB. Once that propagates fully, it will be available in the epel10 (10.1) buildroot to build against. If you're a RHEL customer you can file a support case to request it also get added to the current RHEL minor version (e.g. 10.0), but to be honest it's not very likely to be approved.
If it matters, I'll put an alert in my calendar to retire the package in October.
Yes, I recommend doing this. I'll go ahead and approve this for now just in case any other packages need iniparser-devel, but it sounds like netatalk won't be needing since it probably can't be updated as you described due to breaking changes. If you want to discuss this further feel free to reach out to myself and others in the EPEL matrix channel or on the epel-devel mailing list.
@releng-bot valid
It seems likely that releng-bot is impacted by ongoing datacenter move. I'll try this again once things are back online.
Error happened during processing:
Traceback (most recent call last): File "/opt/app-root/src/toddlers/plugins/scm_request_processor.py", line 192, in process self.process_comment(issue) File "/opt/app-root/src/toddlers/plugins/scm_request_processor.py", line 259, in process_comment self._create_new_repo(issue, issue_body_json) File "/opt/app-root/src/toddlers/plugins/scm_request_processor.py", line 658, in _create_new_repo self.dist_git.new_project( File "/opt/app-root/src/toddlers/utils/pagure.py", line 373, in new_project raise PagureError( toddlers.exceptions.pagure_error.PagureError: Couldn't create project 'rpms/iniparser-epel' Request to 'https://src.fedoraproject.org/api/0/new': {'namespace': 'rpms', 'name': 'iniparser-epel', 'default_branch': 'rawhide', 'description': 'The iniparser-epel package\n', 'url': '', 'wait': True, 'create_readme': True} Response: None Status code: 500
The Pagure repository was created at https://src.fedoraproject.org/rpms/iniparser-epel
Metadata Update from @releng-bot: - Issue close_status updated to: Processed - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.