#808 Koji 1.15.0 stores spec file and such in mock 1.3.4's homedir
Closed: Fixed 5 years ago Opened 6 years ago by puiterwijk.

In builder/kojid, line 4515, it says:

# We can't put this under the mock homedir because that directory
# is completely blown away and recreated on every mock invocation
scmdir = broot.tmpdir() + '/scmroot'

Then the tmpdir is defined as: base = "/builddir/tmp".

The problem is that mock, at least with version 1.3.4, uses /builddir as the home directory: DEBUG util.py:522: Executing command: ['/usr/sbin/useradd', '-o', '-m', '-u', '1000', '-g', '425', '-d', '/builddir', '-n', 'mockbuild'] with env {'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOME': '/builddir', 'HOSTNAME': 'mock', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 'printf "\\033]0;<mock-chroot>\\007"', 'PS1': '<mock-chroot> \\s-\\v\\$ ', 'LANG': 'en_US.UTF-8'} and shell False.

So this means that the used tmpdir is actually exactly in the users' homedirectory which, as the comment says, is blown away on every run.

This means that buildSRPMfromSCM tasks fail with koji-1.15.0 and mock-1.34 .


Note that for Fedora, we currently have a hotfix to work around this by just changing the buildroot directory used for buildSRPMfromSCM (https://src.fedoraproject.org/rpms/koji/blob/master/f/koji-fix808.patch), which fixes our production instance, but I am not sure what directory people intend to use in upstream koji.

using our own namespace for this seems like a sane idea /scmtmp/ or something completely unique like it

Isn't it a duplicate of https://pagure.io/koji/issue/786 ? We've solved it by making tempdir configurable.

Yep, this is a duplicate. Would it maybe be an idea to look at a koji 1.15.1 with this and other important patches, since there's no 1.16.0 soonish I think?

Or if no 1.15.1, at least a page with "known bugs" in the docs?

The main reason I'm suggesting this is the impact of this particular bug (no working createSRPMfromSCM without workaround).

This has gotten backported to the 1.15.1 release, and is fixed for 1.16.0.
This bug is now fixed, thanks!

Metadata Update from @puiterwijk:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

5 years ago

Metadata Update from @tkopecek:
- Issue set to the milestone: 1.16

5 years ago

Login to comment on this ticket.

Metadata