Description of problem: I don't know if this is intentional or not in the current epel-testing version: In the previous version, you could build one package and build a second in the same root directly with --no-clean to save time. That now fails with ERROR: Expected to find single rebuilt srpm, found 2. Version-Release number of selected component (if applicable): 1.2.3-1
That is intentional. I do not want to support concurent usage of the same buildroot. The builds may affect each other and therefore the build is not reproducible any more. If you want to run two builds in parallel, then use: mock --uniqueext=build1 package1.src.rpm mock --uniqueext=build2 package2.src.rpm Or you can run mockchain which automatize this.
I'm sure the reporter didn't mean concurrently, but in succession, because I'm also having the same problem. And I would consider this to be supported use case, since it preserves the build stability if used correctly (if the BuildRequires of the second package are the same or subset of the first). The problem is a consequence of #483486. I think a solution to have both this and nosrc builds would be to delete the builddir except the SOURCES directory. The SRPMS, RPMS, SPECS, BUILD and BUILDROOT should be deleted. I will make the patch if you agree.
For what it's worth, I didn't mean parallel builds (which didn't work in the previous version as far as I know), just building one and re-using the root some time after it's finished. (Of course, I realize it can make things non-reproducible.) Experimentally, --uniqueext doesn't do the same thing, though it's not clear from the doc -- you still get the dependencies reinstalled.
*nod* removing /builddir/build/{SRPM,RPMS,SPECS,BUILD,BUILDROOT,originals}/* sounds good to me. Well removing /builddir/build/SRPM would be sufficient as well. Feel free Michael to make the patch.
*** Bug 1173563 has been marked as a duplicate of this bug. ***
(In reply to Miroslav Suchý from comment #4) > Well removing /builddir/build/SRPM would be sufficient This is not enough of course, because it leaves the resulting rpms in RPMS directory.
I already sent patch upstream, I'm including the commit message to clarify the proposed solution: With --no-clean, delete /builddir except build/SOURCES [RHBZ#1173126] In order to be able to have the ability to execute more successive builds with --no-clean, it's necessary to cleanup build directories from the previous build. Now the whole /builddir is deleted except SOURCES directory which is retained to support nosrc builds. This is further configurable with new config option 'exclude_from_homedir_cleanup', which contains a list of paths relative to /builddir that will be excluded from deletion in prebuild. To put it simply, by default it deletes everything in the /builddir except /builddir/build/SOURCES. And this is further configurable for people who want to delete everything/keep more files.
Could you please clarify why to keep SOURCES? What is it nosrc build?
> because it leaves the resulting rpms in RPMS directory. but that is not a problem. Only problem is populated SRPM directory, because mock then does not know for sure which src.rpm should be used. > Could you please clarify why to keep SOURCES? What is it nosrc build? See bug 483486. For example see: http://developerblog.redhat.com/2014/12/10/how-to-package-proprietary-software/ I must admit this was new to me as well. > To put it simply, by default it deletes everything in the /builddir except /builddir/build/SOURCES. I would suggest to remove only /builddir/build/* except SOURCES. The fact that previously whole /builddir was deleted is just coincidence. It was bug in code (it was removed when user was removed) and not intentional. If user want to clean it he should not use --no-clean at first place.
(In reply to Miroslav Suchý from comment #9) > I would suggest to remove only /builddir/build/* except SOURCES. The fact > that previously whole /builddir was deleted is just coincidence. It was bug > in code (it was removed when user was removed) and not intentional. If user > want to clean it he should not use --no-clean at first place. Actually this is preferred solution for me as well, since it keeps bash history in case I need to used shell in between builds.
(In reply to Miroslav Suchý from comment #9) > > because it leaves the resulting rpms in RPMS directory. > > but that is not a problem. Only problem is populated SRPM directory, because > mock then does not know for sure which src.rpm should be used. That will cause all the RPMS being copied to the resultdir, so even those which were built during previous runs. Not a big problem though, there are more important issues. > > > Could you please clarify why to keep SOURCES? What is it nosrc build? > > See bug 483486. For example see: > http://developerblog.redhat.com/2014/12/10/how-to-package-proprietary- > software/ > I must admit this was new to me as well. > > > To put it simply, by default it deletes everything in the /builddir except /builddir/build/SOURCES. > > I would suggest to remove only /builddir/build/* except SOURCES. The fact > that previously whole /builddir was deleted is just coincidence. It was bug > in code (it was removed when user was removed) and not intentional. If user > want to clean it he should not use --no-clean at first place. I believe it was intentional. There are programs that put their caches, generated files or other data in $HOME (usually hidden files/dirs) and some of them are run during build of packages. Therefore keeping those files threaten the build stability. (In reply to Vít Ondruch from comment #10) > (In reply to Miroslav Suchý from comment #9) > > I would suggest to remove only /builddir/build/* except SOURCES. The fact > > that previously whole /builddir was deleted is just coincidence. It was bug > > in code (it was removed when user was removed) and not intentional. If user > > want to clean it he should not use --no-clean at first place. > > Actually this is preferred solution for me as well, since it keeps bash > history in case I need to used shell in between builds. The proposed solution makes it configurable, so keeping the bash history could be enabled with config_opts['exclude_from_homedir_cleanup'].append('.bash_history') But it's probably a good idea to have .bash_history there by default.
(In reply to Michael Simacek from comment #11) > (In reply to Miroslav Suchý from comment #9) > > > because it leaves the resulting rpms in RPMS directory. > > > > but that is not a problem. Only problem is populated SRPM directory, because > > mock then does not know for sure which src.rpm should be used. > > That will cause all the RPMS being copied to the resultdir, so even those > which were built during previous runs. Not a big problem though, there are > more important issues. Yes, that was my original concern > > > Could you please clarify why to keep SOURCES? What is it nosrc build? > > > > See bug 483486. For example see: > > http://developerblog.redhat.com/2014/12/10/how-to-package-proprietary- > > software/ > > I must admit this was new to me as well. > > > > > To put it simply, by default it deletes everything in the /builddir except /builddir/build/SOURCES. > > > > I would suggest to remove only /builddir/build/* except SOURCES. The fact > > that previously whole /builddir was deleted is just coincidence. It was bug > > in code (it was removed when user was removed) and not intentional. If user > > want to clean it he should not use --no-clean at first place. > > I believe it was intentional. There are programs that put their caches, > generated files or other data in $HOME (usually hidden files/dirs) and some > of them are run during build of packages. Therefore keeping those files > threaten the build stability. This might be the reason. But there are also other locations, where some build output may remain IMO. Not a big concern for me. > (In reply to Vít Ondruch from comment #10) > > (In reply to Miroslav Suchý from comment #9) > > > I would suggest to remove only /builddir/build/* except SOURCES. The fact > > > that previously whole /builddir was deleted is just coincidence. It was bug > > > in code (it was removed when user was removed) and not intentional. If user > > > want to clean it he should not use --no-clean at first place. > > > > Actually this is preferred solution for me as well, since it keeps bash > > history in case I need to used shell in between builds. > > The proposed solution makes it configurable, so keeping the bash history > could be enabled with > config_opts['exclude_from_homedir_cleanup'].append('.bash_history') > > But it's probably a good idea to have .bash_history there by default. +1 for .bash_history
Hi, 1 - this is not Fedora EPEL bug, is fedora bug. 2 - bug #1171601 is a consequence of this bug . 3 - bug #1168116 seems also a consequence of this bug . (In reply to Miroslav Suchý from comment #4) > *nod* removing /builddir/build/{SRPM,RPMS,SPECS,BUILD,BUILDROOT,originals}/* > sounds good to me. Well removing /builddir/build/SRPM would be sufficient > as well. > > Feel free Michael to make the patch. The patch is revert the code that prevent cleaning /builddir/build/ before --no-clean --rebuild
Applied upstream as commits 405a623, 3698470. Behavior is as described in #c7. I also sent followup patch to exclude .bash_history.
mock-1.2.4-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/mock-1.2.4-1.fc21
mock-1.2.4-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/mock-1.2.4-1.fc20
mock-1.2.4-1.el7 has been submitted as an update for Fedora EPEL 7. https://admin.fedoraproject.org/updates/mock-1.2.4-1.el7
mock-1.2.4-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/mock-1.2.4-1.el6
Package mock-1.2.4-1.el7: * should fix your issue, * was pushed to the Fedora EPEL 7 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing mock-1.2.4-1.el7' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0312/mock-1.2.4-1.el7 then log in and leave karma (feedback).
Created attachment 981002 [details] fedora-review log hi! As i mentioned in https://admin.fedoraproject.org/updates/FEDORA-2015-0784/mock-1.2.4-1.fc21 here is the log: $ mock --version 1.2.4
(In reply to Florian "der-flo" Lehner from comment #20) > Created attachment 981002 [details] > fedora-review log > > hi! > > As i mentioned in > https://admin.fedoraproject.org/updates/FEDORA-2015-0784/mock-1.2.4-1.fc21 > here is the log: > > $ mock --version > 1.2.4 Could you please post your `fedora-review.log`, too? It's located inside "/home/$USER/.cache/fedora-review.log"
That is bug in fedora-review. See bug 1151943.
mock-1.2.4-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
mock-1.2.4-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
mock-1.2.5-1.el7 has been submitted as an update for Fedora EPEL 7. https://admin.fedoraproject.org/updates/mock-1.2.5-1.el7
mock-1.2.5-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/mock-1.2.5-1.el6
mock-1.2.5-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/mock-1.2.5-1.fc20
mock-1.2.5-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/mock-1.2.5-1.fc21
mock-1.2.5-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
mock-1.2.6-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/mock-1.2.6-1.el6
mock-1.2.6-1.el7 has been submitted as an update for Fedora EPEL 7. https://admin.fedoraproject.org/updates/mock-1.2.6-1.el7
mock-1.2.6-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/mock-1.2.6-1.fc20
mock-1.2.6-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/mock-1.2.6-1.fc21
mock-1.2.6-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
mock-1.2.6-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
mock-1.2.6-1.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.
mock-1.2.6-1.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.