Description of problem: When building anaconda in mock, the dnf builddep step exits with status after installing the packages and before verifying them, with no indication that anything actually went wrong. Version-Release number of selected component (if applicable): dnf-1.1.1-2.fc24.noarch How reproducible: This has been difficult to pin down. This problem always occurs in anaconda's jenkins jobs, but attempts to run mock outside of jenkins using the same host do not hit the error. I have a rawhide VM that hits the error most of the time, but every in a while succeeds, and I'm not sure what changed. Additional info: Attaching logs.
Created attachment 1074579 [details] build.log build.log from mock
Created attachment 1074580 [details] dnf.log /var/log/dnf.log from the mock buildroot
Created attachment 1074581 [details] dnf.rpm.log /var/log/dnf.rpm.log from the mock buildroot
Created attachment 1074582 [details] dnf.librepo.log /var/log/dnf.librepo.log from the mock buildroot
If there is anything else I can do to provide information, please let me know. This has so far proven impossible to debug and it is preventing us building anaconda packages for rawhide.
I don't see any error in the logs, do you? I think that the root.log contains the output of the "builddep" usage. Can you share it please? BTW, as a workaround, you should be able to use the Mock's --yum switch (or the corresponding config option).
Created attachment 1074584 [details] root.log root.log from mock that I meant to attach the first time around Too many logs and I got them confused, I guess. There's a bunch of warnings about desktop schema stuff, and then it sits for a few seconds, and then it exits with status 1. I don't think the warnings are fatal, or at least they aren't supposed to be.
--yum works, thank you for that. It hadn't even occurred to me.
Right, I cannot reproduce it neither. Could you provide the SRPM as well please?
BTW, I think I can confirm that the warnings are not fatal since I got them as well but builddep have finished successfully.
Created attachment 1074854 [details] anaconda-24.3-0.1.20150918122117.fc24.src.rpm The error happens during anaconda's rc-release make target, which edits a new version into the spec file, runs make dist to generate the source tarball, and then runs: mock -r fedora-rawhide-x86_64 --scrub all mock -r fedora-rawhide-x86_64 --buildsrpm --spec ./anaconda.spec --sources . --resultdir . mock -r fedora-rawhide-x86_64 --rebuild *src.rpm --resultdir . Building the srpm seems to go fine, but the rpm fails. Attaching the srpm from the second mock command.
Created attachment 1074855 [details] make.log This is the output from 'make rc-release' in case there's something in there I missed.
I've narrowed the problem down somewhat. The exit is happening in rpm, in rpmdbCheckSignals. I still don't know why it's failing, but maybe don't call exit() in a library?
The signal is SIGPIPE, and the cause is the fwrite call in runExtScript, at line 376 of lib/rpmscript.c. It happens while executing "/usr/bin/mandb -q\n\n# update cache" as part of the trigger for man-db.
It should be fixed in rpm-4.13.0-0.rc1.9.fc24
Thank you very much. It works for me and finally I can use mock with dnf on rawhide.
Could we get a build/update for f23 for this issue? We are trying to move the builders over to f23 and I think we are hitting this with some builds. See: http://koji.fedoraproject.org/koji/taskinfo?taskID=11749874 and https://lists.fedoraproject.org/pipermail/devel/2015-November/216592.html
I open the bug for f23.
rpm-4.13.0-0.rc1.6.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-5d1b3d3854
Thanks!
rpm-4.13.0-0.rc1.6.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update rpm' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-5d1b3d3854
rpm-4.13.0-0.rc1.6.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 1317843 has been marked as a duplicate of this bug. ***
So I tried turning image generation back on for openQA, and it looks like x86_64 images built OK, but i686 failed. Did you forget to refresh the i686 base image as well as the x86_64 one?
yes...that seems to be the case: [ ] fedora-23-aarch64-nvram.xz 12-Nov-2015 13:11 10K [ ] fedora-23-aarch64.xz 12-Nov-2015 13:09 206M [ ] fedora-23-armv7l.xz 02-Mar-2016 11:03 231M [ ] fedora-23-i686.xz 05-Dec-2015 18:30 247M [ ] fedora-23-ppc64.xz 19-Dec-2015 08:31 268M [ ] fedora-23-ppc64le.xz 19-Dec-2015 16:31 265M [ ] fedora-23.xz 30-Mar-2016 06:25 303M so 'fedora-23.xz' (presumably the x86_64 base image) was rebuilt today, but none of the other arches was.