#9213 Mass rebuild rebuilds epel-only packages in rawhide buildroot
Closed: Fixed a year ago by churchyard. Opened a year ago by churchyard.

  • Describe the issue

Some our our epel7 only packages, such as:

https://src.fedoraproject.org/rpms/python-pip-epel
https://src.fedoraproject.org/rpms/python2-wheel
https://src.fedoraproject.org/rpms/python34-setuptools

Were included in the Fedora 32 mass rebuid. There are Fedora 32 mass rebuid commits and the builds were done in the f32-rebuild tag, such as:

python-pip-epel https://koji.fedoraproject.org/koji/taskinfo?taskID=41252272
python2-wheel https://koji.fedoraproject.org/koji/taskinfo?taskID=41257330
python34-setuptools https://koji.fedoraproject.org/koji/taskinfo?taskID=41257500

Fortunately, they have failed, which is how we have realized this.
Would they succeed, this might generete a rather messy situation later.

Please, stop doing this and untag all such successful builds.

  • When do you need this? ASAP

  • When is this no longer needed or useful? Once we decide to merge epel7 and rawhide maybe?

  • If we cannot complete your request, what is the impact? Unintended packages in Fedora, possibly conflicting or even overriding regular Fedora packages.


I thought this is caused by the fact that all 3 packages have the epel7 branch as default and no master branch. Yet this hasn't happen in https://src.fedoraproject.org/rpms/python3-rpm which is also the same case.

I think I have figured out the cause:

$ koji list-pkgs  --show-blocked --tag f32 --package python3-rpm
Package                 Tag                     Extra Arches     Owner          
----------------------- ----------------------- ---------------- ---------------
python3-rpm             f32                                      releng          [BLOCKED]

$ koji list-pkgs  --show-blocked --tag f32 --package python-pip-epel
Package                 Tag                     Extra Arches     Owner          
----------------------- ----------------------- ---------------- ---------------
python-pip-epel         f32                                      releng    

https://pagure.io/releng/blob/master/f/scripts/mass-rebuild.py IMHO needs to checkout master and fail if master is not present. Leaving this open to do so and opened also https://pagure.io/releng/issue/9231

According to the EPEL FAQ, there should still be master branches for EPEL-only packages and they need to be retired:
https://fedoraproject.org/wiki/EPEL/FAQ#Is_it_possible_to_get_a_package_only_into_EPEL_and_not_Fedora.3F

The current tool to process new package requests seems to confirm that it is still true that the master branch will be created:
https://pagure.io/fedscm-admin/blob/master/f/fedscm_admin/utils.py#_436

According to https://pdc.fedoraproject.org/rest_api/v1/component-branches/?global_component=python-pip-epel at least python-pip-epel has also active branches for f31 and master in PDC.

I filed an issue for fedscm-admin to also create the master branch in pagure when it is created in PDC:
https://pagure.io/fedscm-admin/issue/28

A fix is in https://pagure.io/releng/pull-request/9232

(Even packages with a master branch but with a different default branch are possibly affected by this, not just packages not retired properly.)

According to the EPEL FAQ, there should still be master branches for EPEL-only packages and they need to be retired:
https://fedoraproject.org/wiki/EPEL/FAQ#Is_it_possible_to_get_a_package_only_into_EPEL_and_not_Fedora.3F

Note that the "Due to technical reasons, a master branch for Rawhide will always be created." sentence predates Pagure and is no longer true.

According to the EPEL FAQ, there should still be master branches for EPEL-only packages and they need to be retired:
https://fedoraproject.org/wiki/EPEL/FAQ#Is_it_possible_to_get_a_package_only_into_EPEL_and_not_Fedora.3F

Note that the "Due to technical reasons, a master branch for Rawhide will always be created." sentence predates Pagure and is no longer true.

The branch is still created in PDC at the moment which is the source for the koji package status and therefore this branch still needs to be retired.

That part is correct. But we should IMHO strive to "not create the branch in PDC" instead of "always create the branch in Pagure".

That part is correct. But we should IMHO strive to "not create the branch in PDC" instead of "always create the branch in Pagure".

This might be good idea but it should happen in a coordinated effort to make sure that no process expects the master branch to always exist. The current situation for the packages does not seem to be intended.

Metadata Update from @syeghiay:
- Issue assigned to mohanboddu

a year ago

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

a year ago

Login to comment on this ticket.

Metadata