Bug 1528414

Hmm, I spent 30 minutes debugging it and I have no idea, why this is happening. :(

I see:

py/mockbuild/util.py:def mkdirIfAbsent(*args):


and isn't it this at 478


[herrold@centos-7 mock-1.4.8]$ nl -ba   ./py/mockbuild/util.py | grep -b5 -A5 478
18696-   473                        lines = [process_input(line) for line in lines]
18771-   474                    processed_input = '\n'.join(lines) + '\n'
18836-   475                    if logger is not None:
18882-   476                        for line in lines:
18928-   477                            if line != '':

18974:   478                                line = ansi_escape.sub('', line)

19042-   479                                logger.debug(line)
19096-   480                        for h in logger.handlers:
19149-   481                            h.flush()
19190-   482                    if returnOutput:
19230-   483                        output += processed_input
[herrold@centos-7 mock-1.4.8]$ 

which fails at 479  because the logging path for 'logger.debug(line)' to write to, did not exist?

I am certainly no expert in reading Python error messages, but there is a line number there

let me know if you need anything

The path into which it seeks to write exists (partially)

ls -al [herrold@centos-7 ~]$ ls -al /var/log/journal
-rwxr-sr-x+ 1 root systemd-journal 0 Dec 14 15:03 /var/log/journal
[herrold@centos-7 ~]$ 


note the unusual SGID permissions

As I said off bug:

The fix for:
        https://bugzilla.redhat.com/show_bug.cgi?id=1528414

looks like a simple:
        
         mkdir -p ` dirname logfile_name `

and so, an EASYFIX and low (negligible) risk

I cannot fix it in the .spec file, as the sub-directory seems to be a hash.  It is unclear to me _how_ that hash is arrived at.  I _think_ it is set here (two places):

[herrold@centos-7 mock-1.4.8]$ egrep -r logger * | grep "py" | nl -ba | grep "logging.getLogger" 

    13  py/mockbuild/trace_decorator.py:        logger = logging.getLogger(self.name)

    29  py/mockbuild/util.py:    mockbuild_logger = logging.getLogger('mockbuild')

and adding the utility function after each sub-directory is identified may solve this:

py/mockbuild/util.py:def mkdirIfAbsent(*args):

Created attachment 1383477 [details]
testing path on mkdir once hash name is known

I am testing this presently

Created attachment 1383479 [details]
some success

Tere is a transcript of the build with that patch in place ... it got past the earlier failure point, and now has a more useful log

I make no claim to being Python literate, but perhaps this rubric:

   adding those: mkdirIfAbsent() at a point of failure

is a way to partition the problem?

I suspect I also have a mkdir where it should not be in those eight I added in the attached prior patch

[root@centos-7 mock-1.4.8]# grep "mkdirIfAbsent" util-mkdir.patch | wc -l
8

in case it matters, the 'fedora-review' I am using is:

fedora-review    /var/ftp/pub/nfs/mirror/redhat/epel/7/Packages/f/fedora-review-0.5.3-2.el7.src.rpm

interestingly, I am not getting SElinux denials once past the first item

type=USER_AVC msg=audit(1516379905.117:47328): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  denied  { stop } for auid=n/a uid=0 gid=0 path="/run/systemd/system/machine-86355ec3dedd4b5784e215aefd50b775.scope" cmdline="/usr/lib/systemd/systemd-machined" scontext=system_u:system_r:systemd_machined_t:s0 tcontext=system_u:object_r:systemd_unit_file_t:s0 tclass=service  exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'


Do you want this in a separate bug, cloned from this one?

This package has changed maintainer in the Fedora.
Reassigning to the new maintainer of this component.

I can not reproduce with the version of mock that is right now in
epel-testing, even though fedora-review tool fails on something
different (see bug 1819642).

That said, I believe the original traceback _is_ fixed in current v2.1
mock so I'll attach this bug to the existing bodhi update.

FEDORA-EPEL-2020-88ef4b4d66 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-88ef4b4d66

FEDORA-EPEL-2020-88ef4b4d66 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-88ef4b4d66

FEDORA-EPEL-2020-88ef4b4d66 has been pushed to the Fedora EPEL 7 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-88ef4b4d66

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-EPEL-2020-88ef4b4d66 has been pushed to the Fedora EPEL 7 stable repository.
If problem still persists, please make note of it in this bug report.