Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be unavailable on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1488121 - Monitoring page shows package has been forked but it has not
Summary: Monitoring page shows package has been forked but it has not
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Copr
Classification: Community
Component: backend
Version: unspecified
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
Assignee: Miroslav Suchý
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-09-04 11:23 UTC by Michael Mráka
Modified: 2019-12-06 07:51 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-12-06 07:51:35 UTC


Attachments (Terms of Use)

Description Michael Mráka 2017-09-04 11:23:58 UTC
Description of problem:
https://copr.fedorainfracloud.org/coprs/g/spacewalkproject/spacewalk-2.7/monitor/
shows 
susestudio-java-client 	forked 	forked 	forked 	forked 	forked 	forked 	forked

Forked link references build
https://copr.fedorainfracloud.org/coprs/g/spacewalkproject/spacewalk-2.7/build/593253/

Actual repos for some of the arches do not contain susestudio-java-client package; e.g.
https://copr-be.cloud.fedoraproject.org/results/@spacewalkproject/spacewalk-2.7/epel-7-x86_64/

Neither primary.xml.gz there references susestudio-java-client.


Expected result:
susestudio-java-client included in the repo and referenced in the metadata.

Additional info:
It causes other package build failure
https://copr.fedorainfracloud.org/coprs/g/spacewalkproject/spacewalk-2.7/build/597933/

Comment 1 Pavel Raiskup 2017-09-05 15:01:36 UTC
The same happened to me with 'Follow Fedora branching' enabled in
@db-sig/sclo-postgresql96 project.

Comment 2 clime 2017-09-20 11:01:31 UTC
(In reply to Michael Mráka from comment #0)
> Description of problem:
> https://copr.fedorainfracloud.org/coprs/g/spacewalkproject/spacewalk-2.7/
> monitor/
> shows 
> susestudio-java-client 	forked 	forked 	forked 	forked 	forked 	forked 
> forked
> 
> Forked link references build
> https://copr.fedorainfracloud.org/coprs/g/spacewalkproject/spacewalk-2.7/
> build/593253/
> 
> Actual repos for some of the arches do not contain susestudio-java-client
> package; e.g.
> https://copr-be.cloud.fedoraproject.org/results/@spacewalkproject/spacewalk-
> 2.7/epel-7-x86_64/

I think, it's because the built rpm packages were not in the epel-7-x86_64 chroot dir when it was being forked. Very likely it was auto-pruned before that. prunerepo sometimes takes away packages from the latest build even if they are the latest ones but that happens only if those same NEVRAs are built in some other build as well.

This is very likely what happened there. See:

https://copr.fedorainfracloud.org/coprs/g/spacewalkproject/nightly/package/susestudio-java-client/

The actual problem is in the forking algorithm in my opinion, which does not look at what is at backend but instead it just copies a build db records and it calls backend fork action for each latest successfull build of the package. It assumes, the latest successful build will have all the latest NEVRAs for each project chroot (or rather for each project chroot where the package should be built and present in the project), which might not always be true. 

The similar thing probably happened to Pavel as well in a slightly different flavor (e.g. a build of a package for fedora-rawhide-x86_64 and later build of that same package for fedora-rawhide-i386 -> it will actually fork just the results for fedora-rawhide-i386) but the monitor status page should correctly reflect that then and also the forked build should correctly reflect that then (showing 'forked' for forked chroots and dash '-' for all the rest).

Probably Pavel's bug encounter was exactly the same (building for all the rawhide chroots, some rawhide chroot failed then rebuilding again for all rawhide chroots and it succeded).

Comment 3 Michael Mráka 2018-03-01 08:28:41 UTC
(In reply to Pavel Raiskup from comment #1)
> The same happened to me with 'Follow Fedora branching' enabled in
> @db-sig/sclo-postgresql96 project.

And it happened again with 'Follow Fedora branching' and release Fedora28.

Comment 4 clime 2018-03-01 12:19:05 UTC
(In reply to Michael Mráka from comment #3)
> (In reply to Pavel Raiskup from comment #1)
> > The same happened to me with 'Follow Fedora branching' enabled in
> > @db-sig/sclo-postgresql96 project.
> 
> And it happened again with 'Follow Fedora branching' and release Fedora28.

I will look if I can improve prunerepo. If not, we will need to change the forking algo.

Comment 6 Pavel Raiskup 2019-11-06 14:22:38 UTC
I believe this has been fixed by:
https://pagure.io/copr/copr/c/a9b4c53ecb4d1b64d7352bcf4fdda3d033d3c38d
https://pagure.io/copr/copr/c/e7e661a53661844cac0fd5e0f67013b27747576f

The second patch is not yet released.


Note You need to log in before you can comment on or make changes to this bug.