Hi, sorry for late reply.

We are currently under way to move the whole thing to pagure, so this will take sime time. That said, this looks interesting! However, it needs some time I don't have right now.

Teaching f-r to create a srpm... I don't follow you here. The starting point is always a srpm, and I think it's not removed. The exception is when using prebuilt rpms, but in that case I think it's hard; even in this case we need to trust user to provide the srpm; right?

Just cc me on pagure, once you are done moving ;-)

I don't like the fact that f-r needs a srpm as an input due to the fact that pkgs later works on source files. And it much easy for the user to put all these files in a git repo especially if you don't have a fedora system at hand.

To put this in a greater context, what I am aiming for it a github-based review system for spec files using fedora-review on Travis-CI to lower the threshold to contribute to fedora.
This by no means should replace the review on bugzilla, but act as a standardized pre-filter, before submitting stuff.

I have all the pieces in place, I just need the above feature to make it easier to use. If you want to play with that reviewing system, just fork https://github.com/junghans/fedora-review, change one of the spec files in there and send me a pull request. The pull request will trigger a fedora-review run incl. review.txt.

Well, he have moved... For me, the generic ENOTIME is still a major problem, though. What's the status for this these days from your perspective?

The .travis.yml worked nice for a long time (the meat is in the 20 lines of the script: block), but recently there was an error:

DEBUG util.py:450:  Failed to retrieve machine ID: No medium found
DEBUG util.py:450:  Attempted to remove disk file system, and we can't allow that.

which I think has something to do with calling systemd-nspawn inside docker.

The issue is that the Docker container's /etc/machine-id exists but is empty. I am unsure if this breakage is because of a change in Docker, or a change in the docker.io/fedora image. Running systemd-machine-id-setup inside of the Docker container before running systemd-spawn inside of the Docker container should work around (at least that part of) the issue.

@lukeshu adding systemd-machine-id-setup help for that issue, so now it is stuck with:

DEBUG util.py:579:  Executing command: ['/usr/bin/systemd-nspawn', '-q', '-M', '05a6b9d2fcdd4e57957c936ae0aed969', '-D', '/var/lib/mock/fedora-29-x86_64/root', '-a', '--setenv=TERM=vt100', '--setenv=SHELL=/bin/bash', '--setenv=HOME=/builddir', '--setenv=HOSTNAME=mock', '--setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin', '--setenv=PROMPT_COMMAND=printf "\\033]0;<mock-chroot>\\007"', '--setenv=PS1=<mock-chroot> \\s-\\v\\$ ', '--setenv=LANG=en_US.UTF-8', '/usr/sbin/userdel', '-f', '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
DEBUG util.py:325:  Unsharing. Flags: 134217728
DEBUG util.py:490:  BUILDSTDERR: Failed to open system bus: No such file or directory
DEBUG util.py:490:  BUILDSTDERR: Attempted to remove disk file system under "/run/systemd/nspawn/propagate/05a6b9d2fcdd4e57957c936ae0aed969", and we can't allow that.
DEBUG util.py:634:  Child return code was: 1

Any idea?

Since the Docker container is probably not running systemd as pid1, you'll need to pass --register=no --keep-unit to systemd-nspawn, to keep it from trying to talk to systemd or machined.

@lukeshu I am running fedora-review -v --mock-config ${MOCK_CONFIG} -n ${PKG}' review inside docker and that calls systemd-nspawn somewhen when mock called, so where would I hand these extra options over?