Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1057415 - latest successful build of package not used for building
Summary: latest successful build of package not used for building
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Copr
Classification: Community
Component: backend
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Adam Samalik
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-24 03:25 UTC by Jens Petersen
Modified: 2014-07-15 12:47 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-07-15 12:47:26 UTC


Attachments (Terms of Use)

Description Jens Petersen 2014-01-24 03:25:09 UTC
Description of problem:
I hope I am understanding how copr repos should work.
I built 3 packages successfully in a copr - then I may
have later deleted some of the failed builds.
Now it seems 2 of the packages I successfully built
are not in my yum repo any more.  This seems surprising
behaviour.

I am referring to https://copr.fedoraproject.org/coprs/petersen/

Steps to Reproduce (not certain):
1. in a copr builds list with various build successes and failures
2. delete some failed builds

Actual results:
Seems rpm of some successful builds no longer in repo

Expected results:
All successful builds to remain in repo unless explicitly deleted.

Comment 1 Jens Petersen 2014-01-24 04:45:27 UTC
Hmm this might well be user error - looking closer I only
one successful build was missing - perhaps it was removed later
by an unsuccessful rebuild I am not sure.

Perhaps the summary should be
"failed rebuild should not delete successful build from repo"?
Anyway with the current design that is what happens.

Comment 2 Jens Petersen 2014-01-24 05:17:18 UTC
Then suggestion: don't allow rebuilding n-v-r until nvr has been deleted.

Comment 3 Miroslav Suchý 2014-01-24 07:53:13 UTC
ad #2 - this (i.e. allow to rebuild with the same nvr) is what a lot of user want

BTW there is no need to delete failed builds. It consume nearly zero space and failed builds will be removed after 14 days anyway.

I will try to reproduce your case.

Comment 4 Jens Petersen 2014-01-24 08:22:23 UTC
(In reply to Miroslav Suchý from comment #3)
> this (i.e. allow to rebuild with the same nvr) is what a lot of user want

Okay - then it would be nice if every successful build
was preserved (at least for 14 days) unless deleted by the user.

> BTW there is no need to delete failed builds. It consume nearly zero space
> and failed builds will be removed after 14 days anyway.

I see - well I mainly just wanted to remove them
to clean up the builds list: I should really make
the builds work locally first before pushing to copr... ;)

Comment 5 Miroslav Suchý 2014-01-24 08:45:40 UTC
Only last successful build (for each package) is keeped indefinitely.
https://fedorahosted.org/copr/wiki/UserDocs#Howlongdoyoukeepthebuilds

Comment 6 Jens Petersen 2014-02-05 05:03:33 UTC
Okay I think I have a similar example of the symptoms again:

https://copr.fedoraproject.org/coprs/petersen/ghc-7.8/builds/

Steps:
1. First built http://kojipkgs.fedoraproject.org//packages/ghc-rpm-macros/1.0.7.3/1.fc20/src/ghc-rpm-macros-1.0.7.3-1.fc20.src.rpm (#
2. used that to build ghc-7.8.0.20140201-29.1.fc21.src.rpm (#1798)
3. then I built ghc-rpm-macros-1.2.2-1.1.fc21.src.rpm (#1877)
4. now I retried to build hscolour-1.20.3-5.fc20.src.rpm (#1879)

=> failed still pulling in old ghc-rpm-macros-1.0.7.3-1.fc20 (from 1)!

5. Deleted ghc-rpm-macros-1.0.7.3-1.fc20 from petersen/ghc-7.8
6. Try now again to build hscolour-1.20.3-5.fc20.src.rpm (#1880)

=> again fails pulling in ghc-rpm-macros-1.0.7.3-1.fc20 and
   not newer ghc-rpm-macros-1.2.2-1.1.fc21 build from step 3.

Am I missing something or what is going wrong?

I see ghc-rpm-macros-1.2.2-1.1.fc21 in the repodata
but why is it not getting used now?

7. I tried a combined build too: #1882
   but it failed in the same way.

I think I hit this too when I originally filed this bug
and finally gave up and started a new copr as a workaround
(I since deleted that original copr).

Comment 7 Jens Petersen 2014-02-05 05:06:07 UTC
Maybe copr cached the mock root if it satisfies the build deps?
If hscolour required ghc-rpm-macros > 1.2 say then it would pull
in the newer build to the buildroot perhaps?  Anyway I find
this behaviour surprising. :)

Comment 8 Miroslav Suchý 2014-02-05 08:05:38 UTC
I see it used. See:
http://copr-be.cloud.fedoraproject.org/results/petersen/ghc-7.8/fedora-20-x86_64/hscolour-1.20.3-5.fc20/root.log
which is root.log of task (#1879)
If you grep for ghc-rpm-macros:
[msuchy@dri//tmp]$ grep ghc-rpm-macros root.log
DEBUG util.py:281:   --> ghc-rpm-macros-1.2.2-1.1.fc20.x86_64
DEBUG util.py:281:   ghc-rpm-macros       x86_64 1.2.2-1.1.fc20           coprbecloudfedoraprojectorg_results_petersen_ghc78
DEBUG util.py:281:    ghc-rpm-macros.x86_64 0:1.2.2-1.1.fc20                                        
DEBUG util.py:281:   --> ghc-rpm-macros-1.2.2-1.1.fc20.x86_64
DEBUG util.py:281:   ghc-rpm-macros       x86_64 1.2.2-1.1.fc20           coprbecloudfedoraprojectorg_results_petersen_ghc78
DEBUG util.py:281:    ghc-rpm-macros.x86_64 0:1.2.2-1.1.fc20

Your problem seems to lay in build.log:
Processing files: hscolour-1.20.3-5.fc20.x86_64
Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.pW5nqi
error: File not found: /builddir/build/BUILDROOT/hscolour-1.20.3-5.fc20.x86_64/usr/share/hscolour-1.20.3
+ umask 022
+ cd /builddir/build/BUILD
+ cd hscolour-1.20.3
+ DOCDIR=/builddir/build/BUILDROOT/hscolour-1.20.3-5.fc20.x86_64/usr/share/doc/hscolour
+ export DOCDIR
+ /usr/bin/mkdir -p /builddir/build/BUILDROOT/hscolour-1.20.3-5.fc20.x86_64/usr/share/doc/hscolour
+ cp -pr LICENCE-GPL /builddir/build/BUILDROOT/hscolour-1.20.3-5.fc20.x86_64/usr/share/doc/hscolour
+ exit 0
RPM build errors:
    File not found: /builddir/build/BUILDROOT/hscolour-1.20.3-5.fc20.x86_64/usr/share/hscolour-1.20.3
Child return code was: 1

Which puzzle me as well, but does not seem to be related to use of incorrect package.

Comment 9 Jens Petersen 2014-02-05 08:58:41 UTC
Well that was the later chain build I did.

The earlier builds were really pulling in ghc-rpm-macros-1.0.7.3-1.fc20
and failing in root.log - I should have pasted the root.log,
but wanted to test the chain build too: so I suppose my step 7
conclusion was incorrect it actually worked but failed
because of spec problem which is ok. :)

(I still wish copr would keep older build logs around but that is another story.
Anyway next time I will save the individual logs.:)

Anyway yes thanks it seems to be working now after the chainbuild #1882 perhaps.
But I suspect there is some issue with updating a package in copr mock buildsys.

Comment 10 Miroslav Suchý 2014-02-05 09:57:00 UTC
Ok. I will later try to reproduce your steps as you described it in #6 and grab log myself.

Comment 11 Jens Petersen 2014-03-10 05:49:56 UTC
This might be the same issue as I saw in bug 1057937.

Comment 12 Adam Samalik 2014-07-07 09:05:22 UTC
Hi Jens, I reproduced the bug in your initial comment and fixed it in commit 265599761af744fdc8e1ab5a70c956bcfe8a5086.

Comment 13 Miroslav Suchý 2014-07-15 12:47:26 UTC
New version, which include this fix, has been deployed to production and build for Fedora rawhide.


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