Bug 455387
Summary: | mock does not handle BUILDROOT dir from new rpm | ||
---|---|---|---|
Product: | [Retired] Fedora Hosted Projects | Reporter: | Till Maas <opensource> |
Component: | mock | Assignee: | Clark Williams <williams> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | unspecified | CC: | dcantrell, jnovy, matt_domsch, meyering, opensource |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | mock-0.9.11-1.fc10.noarch | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-09-10 20:57:31 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Till Maas
2008-07-15 10:34:43 UTC
29 packages currently failing due to this, so please fix it in mock to the package owners of these don't get highly confused. AcetoneISO (mock_bug_455387) aircrack-ng (mock_bug_455387) ctrlproxy (mock_bug_455387) fcgi (mock_bug_455387) fedorawaves-kdm-theme (mock_bug_455387) filesystem (mock_bug_455387) ftplib (mock_bug_455387) kcoloredit (mock_bug_455387) kdeaddons (mock_bug_455387) kdegames3 (mock_bug_455387) kgrab (mock_bug_455387) kiconedit (mock_bug_455387) kmid (mock_bug_455387) ksig (mock_bug_455387) libHX (mock_bug_455387) ocaml-facile (mock_bug_455387) offlineimap (mock_bug_455387) pam_mount (mock_bug_455387) presto (mock_bug_455387) python-docs (mock_bug_455387) python-flup (mock_bug_455387) qimageblitz (mock_bug_455387) radeontool (mock_bug_455387) wyrd (mock_bug_455387) x2vnc (mock_bug_455387) xbiso (mock_bug_455387) xchat-ruby (mock_bug_455387) xmms-cdread (mock_bug_455387) z88dk (mock_bug_455387) Till, So you think a viable fix is for mock just to create BUILDROOT as part of the chroot setup? (In reply to comment #2) > Till, > > So you think a viable fix is for mock just to create BUILDROOT as part of the > chroot setup? Yes. Wait a sec, I'm a little unclear how this is a mock problem, and not an rpm or spec problem. You're trying to create a directory without ensuring the leading paths are there. Don't. Arguably we should change mock so that the %_topdir it uses for it's user is rpmbuild rather than build, but it still seems like there is an rpm bug here, not a mock bug in the mismatch. rpm uses %(echo $HOME)/rpmbuild and %_topdir by default. Does mock define _topdir explicitely? Note that the new rpm doesn't honour Buildroot: tags in spec any more and defines it to %{_buildrootdir}/%{name}-%{version}-%{release}.%{_arch}, where %{_buildrootdir} is %{_topdir}/BUILDROOT. The initial mock setup should create %{_topdir}/BUILDROOT regardless the actual %{_topdir} contents since it is one of the base directories like SPECS, SRPMS, etc now. does BUILDROOT replace BUILD? Or is it an additional directory? Currenly mock does this: for subdir in [self.makeChrootPath(self.builddir, s) for s in ('RPMS', 'SRPMS', 'SOURCES', 'SPECS', 'BUILD', 'originals')]: mock.util.mkdirIfAbsent(subdir) Easy enough to add BUILDROOT to that array, but wondering if we need to delete BUILD? (In reply to comment #6) > does BUILDROOT replace BUILD? Or is it an additional directory? It's an additional directory. Actually, packages are built in BUILD subdir and then installed to buildroot which is in the BUILDROOT directory now. > Currenly mock does this: > > for subdir in [self.makeChrootPath(self.builddir, s) for s in ('RPMS', > 'SRPMS', 'SOURCES', 'SPECS', 'BUILD', 'originals')]: > mock.util.mkdirIfAbsent(subdir) > > Easy enough to add BUILDROOT to that array, but wondering if we need to delete > BUILD? Yup, adding BUILDROOT should solve the bug, but please keep BUILD in the array as well. for how many years have we been teaching people to create BUILD RPMS SRPMS SPECS SOURCES before running rpmbuild? Now we're going to add another directory to this list? Why not let rpmbuild create BUILD/BUILDROOT/ and use that, if it wants to? BUILD/ is unseen by end users generally - it's populated and erased entirely by rpmbuild. So let rpmbuild create BUILD/BUILDROOT/. (In reply to comment #8) > for how many years have we been teaching people to create BUILD RPMS SRPMS > SPECS SOURCES before running rpmbuild? It is irrelevant. RPM is under active development unlike during many years up to now. Some changes are therefore expected, especially in rawhide. We need to properly document it though when rpm-4.6 is out so that users are aware of that. The addition of BUILDROOT directory is just a direct result of obsoleting ill-designed BuildRoot: tag that was subject of misleading guidelines. The fact is that to keep it secure (e.g. two buildroots won't conflicts between two or more parallel builds) rpmbuild has to decide itself where the buildroot will be located and in fact it is configurable either in /usr/lib/rpm/macros system-wide or in .rpmmacros per user. > Now we're going to add another directory to this list? Yes. > Why not let rpmbuild create BUILD/BUILDROOT/ and use > that, if it wants to? Because it doesn't make sense from the directory logic and it's messy. rpmbuild doesn't remove directories in BUILD/ after a package is built. Imagine what amount of directories you would have to pass just to find BUILDROOT subdirectory after you built a few packages. And yes, it by principle allows conflicts among directories where packages are actually built and BUILDROOT directory. So it is unacceptable. > BUILD/ is unseen by end users generally - it's populated > and erased entirely by rpmbuild. So let rpmbuild create BUILD/BUILDROOT/. Not in case when the build fails. In this situation it is very good for a packager to have possibility to look into the buildroot to see what happenned. I'll hold off on a new rawhide rebuild until this bug and #458234 are resolved in mock. Matt, I committed a few days ago to rpm upstream that all needed directories are created if they are missing prior to build/srpm installation. Maybe that resolves also this bug without touching mock. It will occur with the new GIT snapshot in rawhide. Hi Jindrich, Is this fix slated to hit rawhide soon? I'm experiencing problems in ovirt due to it. If it's going to take much longer, it may be worthwhile for me to commit a work-around patch locally. Thanks, Jim btw, I'm using rpm-4.5.90-0.git8461.5.x86_64 The mock which adds the BUILDROOT dir hit rawhide a few days ago (mock-0.9.11-1.fc10.noarch). Is it still a problem? Hi Clark, Thanks for the quick reply. In following ovirt's build instructions (http://ovirt.org/build-instructions.html) on rawhide, I get this failure due to a missing BUILDROOT directory: $ make -f ovirt.mk OVIRT_BRANCH=next build ... cp version rpm-build/ rm -rf ovirt-server-0.92 rpmbuild --define ... ... Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.FhFnTO + umask 022 + cd /home/meyering/w/co/ov/server/rpm-build + cd ovirt-server-0.92 + LANG=C + export LANG + unset DISPLAY + test x/home/meyering/w/co/ov/server/rpm-build/BUILDROOT/ovirt-server-0.92-1.fc1 0.x86_64 '!=' x + rm -rf /home/meyering/w/co/ov/server/rpm-build/BUILDROOT/ovirt-server-0.92-1.fc 10.x86_64 + mkdir /home/meyering/w/co/ov/server/rpm-build/BUILDROOT/ovirt-server-0.92-1.fc1 0.x86_64 mkdir: cannot create directory `/home/meyering/w/co/ov/server/rpm-build/BUILDROOT /ovirt-server-0.92-1.fc10.x86_64': No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.FhFnTO (%install) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.FhFnTO (%install) make[1]: *** [rpms] Error 1 make[1]: Leaving directory `/home/meyering/w/co/ov/server' make: *** [publish] Error 1 [Exit 2] Should I report this elsewhere? no, I think that's my problem (mock that is). The output of the error messages makes it look like there was a newline tagged onto the end of BUILDROOT... I'll dig a bit deeper. Ah, that'll teach me to read things more closely! You're not calling mock in your build, so you're seeing the rpm error and you need the rpm that Jindrich was referring to in comment #11. Don't know what the rpm version number is though. I'm going to close this BZ, since the mock fix for this problem is already in rawhide. (In reply to comment #12) > Hi Jindrich, > > Is this fix slated to hit rawhide soon? Yup, I committed and built it in today's rpm-4.5.90-0.git8461.6. |