Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 835633
Summary: | "ERROR: state finish mismatch" when exiting mock --shell | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Ville Skyttä <ville.skytta> |
Component: | mock | Assignee: | Clark Williams <williams> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | amessina, bochecha, kdudka, mebrown, t.h.amundsen, williams |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-11-15 02:32:19 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Attachments: |
Description
Ville Skyttä
2012-06-26 16:37:59 UTC
Yes, sorry I just caught this. It's a bogus error and I have the fix queued for the next release. Created attachment 606100 [details]
[PATCH] fix state start/finish mismatch in --chroot
The same problem happens with --chroot:
$ mock --chroot ls
INFO: mock.py version 1.1.26 starting...
[... snip ...]
ERROR: state finish mismatch: current: chroot ls, state: lock buildroot
Attached patch is similar to the Git commit which fixed the error with --shell (ff524a6713538299463c6553d965b5af6193b1fa)
(In reply to comment #2) > Created attachment 606100 [details] > [PATCH] fix state start/finish mismatch in --chroot > > The same problem happens with --chroot: > $ mock --chroot ls > INFO: mock.py version 1.1.26 starting... > [... snip ...] > ERROR: state finish mismatch: current: chroot ls, state: lock buildroot > > Attached patch is similar to the Git commit which fixed the error with > --shell (ff524a6713538299463c6553d965b5af6193b1fa) Applied to my git tree and will show up in the next release. I don't know if this is related, but I've encountered something similar on my F17 build host in our local Koji installation (using 1.1.26-2.fc17): ERROR: state finish mismatch: current: chroot ['make', 'sources'], state: lock buildroot It fails in SRPM build while doing 'make sources' on a Makefile that only contains this: sources: @echo "Nothing to do here..." I've been trying older mock versions and the latest that works for me is mock-1.1.22-2.1.fc17. (In reply to comment #4) > I don't know if this is related, but I've encountered something similar on > my F17 build host in our local Koji installation (using 1.1.26-2.fc17): > > ERROR: state finish mismatch: current: chroot ['make', 'sources'], state: > lock buildroot Yes, this is probably what you're hitting. (for some reason I wasn't CC-ed on this bug even though I commented, so I never received your reply) (In reply to comment #3) > (In reply to comment #2) > > Created attachment 606100 [details] > > [PATCH] fix state start/finish mismatch in --chroot > > > > The same problem happens with --chroot: > > $ mock --chroot ls > > INFO: mock.py version 1.1.26 starting... > > [... snip ...] > > ERROR: state finish mismatch: current: chroot ls, state: lock buildroot > > > > Attached patch is similar to the Git commit which fixed the error with > > --shell (ff524a6713538299463c6553d965b5af6193b1fa) > > Applied to my git tree and will show up in the next release. First, I can't find the commit in the upstream Git tree. Did you apply verbatim or did you change something? (I'm asking because I rebuild mock with this patch applied, so if I got something wrong it would be nice to know :) Also, I found another instance of the same bug: _setupDev() doesn't try/catch, so any exception it raises is raised to the caller (e.g shell() ). So the self.finish("device setup") never gets called (because it's at the end of _setupDev(), after the exception has been raised), and instead the caller catches the exception and tries to finish its own state (e.g self.finish("shell") ), causing the mismatch. I'll try to cook up a patch to fix it soon. Created attachment 609603 [details] [PATCH] fix state start/finish mismatch on 'device setup' This fixes the problem I described in comment 6. Created attachment 609604 [details] [PATCH] Handle failures in the various setups before --shell While the previous patch fixes the issue I described in comment 6, it only lets mock to fail on yet another start/finish mismatch later on, which this patch fixes. Created attachment 609624 [details]
[PATCH] fix state start/finish mismatch when 'rpmbuild -bs' fails
And one more state mismatch issue.
This one appears when building the srpm fails, for example if you forget to commit/push patches which are referenced in the spec file.
(In reply to comment #6) > First, I can't find the commit in the upstream Git tree. Did you apply > verbatim or did you change something? (I'm asking because I rebuild mock > with this patch applied, so if I got something wrong it would be nice to > know :) > Did you look in the 'work' branch? That is where I do stuff before commiting to a build. Of course it's entirely possible that I hadn't pushed it back to the origin... > Also, I found another instance of the same bug: _setupDev() doesn't > try/catch, so any exception it raises is raised to the caller (e.g shell() ). > > So the self.finish("device setup") never gets called (because it's at the > end of _setupDev(), after the exception has been raised), and instead the > caller catches the exception and tries to finish its own state (e.g > self.finish("shell") ), causing the mismatch. > > I'll try to cook up a patch to fix it soon. I applied the three patches from #c7, #c8 and *c9 to my tree and have pushed it to the main git tree (still in the work branch). mock-1.1.27-2.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/mock-1.1.27-2.el6 mock-1.1.27-2.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/mock-1.1.27-2.fc16 mock-1.0.35-1.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/mock-1.0.35-1.el5 mock-1.1.27-2.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/mock-1.1.27-2.fc17 Package mock-1.1.27-2.el6: * should fix your issue, * was pushed to the Fedora EPEL 6 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing mock-1.1.27-2.el6' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-12915/mock-1.1.27-2.el6 then log in and leave karma (feedback). mock-1.1.28-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/mock-1.1.28-1.el6 mock-1.1.28-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/mock-1.1.28-1.fc18 mock-1.0.36-1.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/mock-1.0.36-1.el5 mock-1.1.28-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/mock-1.1.28-1.fc17 mock-1.1.28-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/mock-1.1.28-1.fc16 mock-1.1.28-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report. mock-1.1.28-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report. mock-1.0.36-1.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report. |